On Wed, Mar 20, 2002 at 12:55:36PM -0800, Thomas Bushnell, BSG wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > The implementation is using the Hurd's IO interface. It seems I was not > > clear enough in my original mail. The translator creates a pipe to the > > forked program, and translates io_read into a pipe read and io_write > > into a pipe write. The translator forks for every open(). > > Everything that uses the IO interface is either a file or a socket. > > > Now, suppose you have a program like wc that collects data and returns > > a summary of that data. It will read from stdin until it gets EOF, and > > then print from stdout. But if I use the above translator, I have only > > one filedescriptor, and I cannot simply close it if I want to read back > > the summary of wc. > > Then you are using a bidirectional pipe: you should really call it a > socketpair. (Exactly how are you creating it?)
We are getting into muddy water again, because I was unprecise. If we call the application A, the translator T and the forked program P, then I have the normal file interface open(), read(), write() between A and T, and a bidirectional pipe created with pipe() between T and P. Note that I will replace this with two pipes, so I can close one without closing the other. I have created the bidirectional pipe with pipe(). Standard pipes are bidirectional on the Hurd (at least I could read and write in both directions, I tested it!). What I was asking about is the interface between A and T. > This is what the shutdown call is for. You shutdown for writing, > which is like closing one half of the pipe. The guy reading on the > other end will get EOF, but the other half of the pipe will be just > fine. Would I use shutdown even for the file interface between A and T, if there exists an agreement between the application and the translator that this is to be used for closing one direction? As an extension to the normal interface. Maybe I am just trying to do the wrong thing. Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
