ford@crash.CTS.COM (Michael Ditto) (06/13/87)
In article <149@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: >Similarly a writer doesn't hang: it can just write its bytes and get out of >there without waiting for a reader to show up. You also don't hang on close >... Actually, you do hang if the pipe is full. This makes System V named pipes essentially useless in my opinion. The main application I see for them is something like a spooler queue. But if the server reading the pipe is busy, and several clients append their requests to the pipe, it becomes full, and the next attempt to queue a request will block. It's too bad there is no way to have a 'FIFO file', where the full file system capabilities are available (unlimited and variable length files), but where the act of reading some bytes causes them to be 'deleted'. An interesting aspect of System V named pipes, though, is that their contents are maintained across reboots. It's just the size limit (usually 5K) that makes them useless.
karl@sugar.UUCP (Karl Lehenbauer) (06/20/87)
> Actually, you do hang if the pipe is full. This makes System V named pipes > essentially useless in my opinion. The main application I see for them is something > like a spooler queue. But if the server reading the pipe is busy, and several > clients append their requests to the pipe, it becomes full, and the next attempt > to queue a request will block. I don't see that hanging on full pipes makes them useless, other than for realtime. After all, hanging's what unnamed ones do. If you don't want programs to hang (very long) on a named pipe, have a receiver sit there reading the thing constantly and buffer the data somewhere. -- uucp: {shell,rice,seismo}!soma!uhnix1!sugar!karl bbs: (713) 933-2440 voice: (713) 933-9134