After some small testing I conclude that SharedBufferStream is much
faster than the class InternalPipe in OSProcess. Sorry David! :-)

InternalPipe uses a SharedQueue of single characters which makes it a
magnitude slower (30-50 times on some simple tests with random length
Strings on in/out, single producer/consumer).

Another thing to note is that InternalPipe is not "safe" for multiple
consumers/producers - it has no protection for consumers or producers
"stealing" characters from each other. SharedBufferStream makes sure
that operations like nextLine, nextPutAll, next: etc are atomic.

We have also looked at BufferStream which is used at the heart of
Comanche (inside SocketStream) and BufferStream has at least one problem
that could/should be fixed - the method nextPutAll: which does:

nextPutAll: aString
	buffer _ (buffer copyFrom: startPos to: endPos), aString.
	startPos _ 1.
	endPos _ buffer size

...instead of trying to fit in aString in the buffer with a
replaceFrom:to:with: as SharedBufferStream does (similar design as
SharedQueue):

nextPutAll: aString
	"Send value through the receiver. If a Process has been suspended 
	waiting for data, allow it to proceed."

	| len |
	accessProtect
		critical: [
			len _ aString size.
			writePosition + len - 1 > buffer size
				ifTrue: [self makeRoomAtEndFor: len].
			buffer replaceFrom: writePosition to: writePosition + len - 1 with:
aString.
			writePosition _ writePosition + len.
			buffered ifFalse:[self ensureSignaled]].
	^aString

Possibly Comanche does not suffer because of this because it might only
do very few (=1) large nextPutAll: (whole pages etc) instead of many
smaller. Anyway, a simple test with filling up a stream with 100 Strings
of random length (1-50) and then doing contents on it (repeated a 1000
times) gave:

SharedBufferStream: 1588 ms (no real difference with different initial
buffer size)
BufferStream Time: 3266 ms

Since SharedBufferStream does many other things slowing it down
BufferStream should be able to spead up A LOT from having a better
nextPutAll:. Left as an exercise to the reader... :-)

regards, Göran