Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

What's the difference between a stream and a queue? They both have the concept of an ordered set of elements, but tend to have different implementations and a different vocabulary of 'insert'/'extract' (streams) vs. 'enqueue'/'dequeue' (queue). Are these interchangable? Do they suggest different concepts or patterns? If so, what are the differences?

share|improve this question
Apparently "stream" refers to different things in different contexts. There are differences in characteristics between a character stream vs. Windows IStream interface in COM vs. an event stream in architecture speak. Can you clarify? – rwong May 24 '13 at 6:47

4 Answers 4

A stream is not really a data structure as such (conceptually), but is a sequence of digitally encoded coherent signals (packets of data or data packets) used to transmit or receive information". So basically a sequence of data.

A queue is a simple FIFO mechanism allowing you to add items to the back of the queue or take from the front.

Streams always have a source, e.g. a file, network location, etc. A Queue does not inherently contain any data.

So essentially they are quite different in concept and as Mason pointed out, they are used differently.

share|improve this answer
There's actually a data structure called "stream", with (effectively) a list of data to consume, with a producer function at its tail, callable if you need more elements. – Vatine May 24 '13 at 10:05
The Unix 'yes' command looks like a stream but has no particular data source. – JBRWilkinson May 24 '13 at 10:18
@JBRWilkinson: Run without an argument, the data source for yes(1) is the embedded default string. Run with an argument, it's whatever provided the argument. – Blrfl May 24 '13 at 11:16
Yes, you're right - all data has to come from somewhere. Perhaps the actual point here is that a queue could be empty and a stream, by definition, is usually not? – JBRWilkinson May 25 '13 at 14:21
@JBRWilkinson: I suppose you could open a stream, send nothing through it and then close it. – Blrfl May 28 '13 at 12:35

In my experience, a stream is a sequence of bytes that are produced/consumed at rate often determined by data within the stream. For example, an MPEG data stream will have frame headers which describe what the next sequence of bytes does and how many need to be consumed. Binary serialisation of a document would be similar. It is not always self-describing : writing to STDOUT can be done in a stream-wise manner but it may be humanly-readable/non-parseable data.

Conversely, a queue is usually of a well-known type of object (or interface-supporting objects) that are consumed in their entirety. An example might be a queue of database jobs that are processed by a number of database workers.

share|improve this answer

The basic difference is in the way they're used. In a stream, you usually only use one side of the operation: you open a stream to read, or write, but not both. Whereas with a queue, you're putting items on and taking them off.

Also, queues are very strict about the order in which you put things on and take them off, while streams often (but not always) support a Seek operation, especially if you're reading from them.

share|improve this answer
FileStream can be opened in ReadWrite mode. – Robert Harvey May 23 '13 at 22:09
..and priority queues gives options about order – Petter Nordlander May 23 '13 at 22:27

A difference between a stream and a queue is the way data rate is controlled:

  • in a queue, the sender adapts to the speed of the reader. The sender decides what to do if the queue is full: wait for availability of queue or throw data away.

  • in a stream, the reader adapts to the speed of the sender, The reader decides what to do if new data arrives before old one has been consumed.

With that perspective, character streams such as Unix pipes would not qualify as streams but as queues.

share|improve this answer
In adaptive video streaming, the server will adjust to a lower fidelity stream because the client isn't keeping up. – JBRWilkinson May 24 '13 at 10:17
@JBRWilkinson - In adaptative video streaming, the server just sends multiple variants of a stream at different bit rates. This is still the responsibility of the client to choose among these streams. – mouviciel May 24 '13 at 11:20
Yeah, HTTP streaming does that. I meant video calling which is point-to-point and the data isn't pre-encoded. My bad - I should've been explicit. – JBRWilkinson May 25 '13 at 14:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.