[erlang-questions] UNIX streams and Erlang ports

Robert Virding robert.virding@REDACTED
Sat Feb 3 01:04:27 CET 2007


I discovered a copy of a very interesting, but rather old, paper by 
Dennis Ritchie called "A Stream Input-Output System" from 1984. It 
describes a new flexible system for communication between user 
applications and devices.

"A stream is a full-duplex connection bwtween a user's process and a 
device or pseudo device. It consists of several linearly connected 
processing modules, and is analagous to a Shell pipeline, except that 
data flows in both directions. The modules in a stream communicate 
almost exclusively by passing messages to thier neighbors. ..."

It is a truly elegant concept.

What makes it especially interesting for us is that this was the model 
on which Erlang ports and i/o was based. Ports represent devices and 
applications communicate with devices by sending/receiving messages, 
i.e. streams. By inserting processes bewtween the port and the 
application the data can be processed along the way, i.e. processing 
modules. This is the reason why originally ports looked almost exactly 
like processes. An application communicated with a device by messages 
and would not see what extra processing was done along the way, or where 
it was done. We actually debated whether to have a separate data type at 
all for ports.

Unfortunatley this model broke when the port_XXX functions were added. 
You now have to know what you are communicating with. Goodbye abstraction.

What I find rather ironic and appeals to my, sometimes twisted, sense of 
humour is part of the manual text describing the port_XXX commands. The 
manual tries to show why the port_XXX commands are much more "logical" 
than the message interface. All I can say is that they, those who added 
the commands and wrote the text, missed the point and that the commands 
are in fact illogical and break the model.

Reading old papers can be fun. You can find Ritchie's paper on his site, 
along with a lot of other interesting stuff.

Robert



More information about the erlang-questions mailing list