Okay. I'm with you.
Yes, that's more or less what would be needed, I think.

	Johnny

Steven M. Bellovin wrote:
> On Tue, 18 Apr 2006 20:07:29 +0200, Johnny Billquist <bqt@update.uu.se>
> wrote:
> 
> 
>>Steven M. Bellovin wrote:
> 
> 
>>>If we had streams, and if pipes were streams, it could be done quite
>>>easily -- make sure there's a 0-length record present.  Otherwise, it's
>>>not particularly easy.  It would take a kernel multiplexor that you handed
>>>several files -- more likely, several file descriptors -- that would read
>>>the first until it ended, give EOF, then the next, etc.
>>
>>Well, it also needs to signal eof at the end of each file, and then 
>>reset the status if another file exists, which to switch over to.
> 
> 
> That's what I said, I think.
> 
>>But I'm not sure about your thoughs... You need read() to return 0. I 
>>don't think a stream have the data stored in records. A stream will 
>>return as much data as exists, or until the read buffer is full. If no 
>>data exists, it will wait. It will only return 0 on a EOF situation.
>>That's what we want to access. I suspect this means that we need some 
>>oob data to tell that en EOF should be delivered here, or the 
>>implementation behind the read needs to be changed.
>>The whole point of a stream is that there isn't any structure to it, 
>>which includes the absence of a record concept.
>>
>>But I might be wrong. It's been a long time since I was anywhere near 
>>that kind of code (back in 4.3BSD...).
>>
>>A pipe can be wrapped in a stream, by the way, can it not? A stream is 
>>just distinguished by the fact that it have a FILE descriptor. When 
>>stdin is redirected to a pipe, it's still a stream?
>>Or am I confusing things a lot now?
>>
> 
> We may be talking past each other.  I'm speaking of System V Release 4
> streams and/or Ritchie streams.  Both were capable of preserving record
> boundaries.
> 
> Without going into details, streams a form of kernel pipeline.  You had
> producers and consumers, but you also had filters.  Thus, a tty device
> would simply generate an uinterpreted byte stream; if you wanted tty
> semantics such as erase and kill, you pushed a line discipline on top of
> the tty fd.  But the same could be done with TCP fds and pipe fds -- no
> need for ptys in that model.  (I'm oversimplifying.)
> 
> Ritchie streams contained a linear sequence of buffers of some maximum
> length.  There were also control records; one was record mark, which (for
> example) the tty line discipline would emit when it saw a ^D.  SVR4
> streams were more like mbuf chains, in that each stream message could be
> the head of a list of buffers.  In this case, a 0-length buffer list
> indicated a record mark.
> 
> We're getting off-topic, but I think it's clear how either scheme would
> let you DTRT for this case.
> 
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol