ted@usceast.UUCP (Ted Nolan) (04/30/85)
Does anyone have a (preferably user level) way to implement sys5 type
fifo files on 4.2 bsd? If I understand the concept correctly, this would
be exactly what I have wanted at many different times (as well as now).
It seems that it could be done somehow with sockets, but I freely admit that
I haven't had to understand them yet and don't.
Thanks
Ted Nolan ..usceast!ted
--
-------------------------------------------------------------------------------
Ted Nolan ...decvax!mcnc!ncsu!ncrcae!usceast!ted (UUCP)
6536 Brookside Circle ...akgua!usceast!ted
Columbia, SC 29206 allegra!usceast!ted@seismo (ARPA, maybe)
("Deep space is my dwelling place, the stars my destination")
-------------------------------------------------------------------------------gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (05/02/85)
> Does anyone have a (preferably user level) way to implement sys5 type > fifo files on 4.2 bsd? If I understand the concept correctly, this would > be exactly what I have wanted at many different times (as well as now). > > It seems that it could be done somehow with sockets, but I freely admit that > I haven't had to understand them yet and don't. I once looked at this and decided that sockets would not suffice. For one thing, FIFO inodes are stored in the file system so they persist across reboots. For another, the 4.2BSD UNIX domain socket code was so buggy that one endangers his system by trying to use it. Fortunately, the S_IFIFO bit pattern has not been usurped by Berkeley yet, so FIFOs could be added to the 4.nBSD kernel without disrupting things. (It would be nice if pipes were put back at the same time.)
ron@BRL (Ron Natalie) (05/02/85)
> For another, the 4.2BSD UNIX domain socket > code was so buggy that one endangers his system by trying to use it. Ah, jeez Doug. For someone who is is always bitching at people who send bug reports out for problems that have been fixed in the latest version of the code, you should have realized that we have actually fixed the problem with the so-called "UNIX IPC" a long time ago. I do admit you are right, Berkeley broke some of the pipe conventions when they switched them over to being sockets such that code no longer works. In addition, I could do FIFO's with the BRL socket inode code, but it would be extrordinarily messy. I would suggest that anyone who really needs them actually implement them. -Ron
chris@umcp-cs.UUCP (Chris Torek) (05/02/85)
> From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) > For another, the 4.2BSD UNIX domain socket code was so buggy that one > endangers his system by trying to use it. Only the SOCK_DGRAM code! Pipes are SOCK_STREAM socketpairs (well, sort of), and only break if you run out of mbufs (but then exit() panics if you run out of mbufs, so why worry about the sockets?). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
gwyn@Brl.ARPA (VLD/VMB) (05/02/85)
Although BRL 4.nBSD has fixed the UNIX domain sockets, that doesn't mean that all 4.2BSD sites have. I thought a warning was in order.
ron@BRL (Ron Natalie) (05/03/85)
The fixes are on the bug lists.
john@genrad.UUCP (John Nelson) (05/03/85)
>> For another, the 4.2BSD UNIX domain socket code was so buggy that one >> endangers his system by trying to use it. > >Only the SOCK_DGRAM code! Pipes are SOCK_STREAM socketpairs (well, >sort of), and only break if you run out of mbufs (but then exit() >panics if you run out of mbufs, so why worry about the sockets?). I hate to disallusion anyone, but SOCK_STREAM is as buggy as SOCK_DGRAM. Whatever you do, DONT USE OUT OF BAND DATA! It will crash the system. I also have a program which crashes both ULTRIX and BSD4.2 as distributed: it calls send and recv on a connected socket pair in SOCK_STREAM. (Actually, it calls send and recv with a missing flags argument - nevertheless, it shouldnt crash the kernel!)