Date: Sat, 23 Aug 1997 04:16:56 -0700 (PDT) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: dk+@ua.net Cc: hackers@freebsd.org Subject: Re: My pipe is getting muddled?! Message-ID: <Pine.LNX.3.95.970823025520.24692B-100000@phobos.illtel.denver.co.us> In-Reply-To: <199708230842.BAA08761@dog.farm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Okay, I posted a question a while back about whether or not it would be okay to > use SYSV message queues in a project. I got a mixed reaction on that, so I'm > looking at FIFO's and/or sockets as well. > > I have one big problem, though: If I have a server sitting on a FIFO, and it > needs to communicate in both directions with multiple clients (imaging something > like the X server sitting on /tmp/.X11-pipe/X0), how do I keep everyone's > messages from getting all mixed up? On a socket, one would sit in a loop and > accept() connections on the server end, and everything just works. > > The thing is, I've been trying to figure out (using truss), how Solaris manages > to do a very similar thing in the X server with FIFO's, and I can't for the life > of me figure out what crazy STREAMS nonsense they're using. The nearest I can > tell, there is some sort of multiplexor in there, because when a new client > connects, the server does an ioctl(fd, I_RECVFD, &buf), and pulls a new file > descriptor out of the stream, and communicates with the client on that. Oddly > enough, the client isn't doing an I_SENDFD anywhere, so I think this is > happening automatically. Can anyone explain what's going on? I believe > /tmp/.X11-pipe/X0 is a new interface, because Solaris also has a > /tmp/.X11-unix/X0, which I believe is how everyone else communicates? I don't have solaris box here (and never seen OpenWindows source, and have enough work to do to have no intent of spending hours looking at the truss output), but X11R6.3 source has I_SENDFD in STREAMS-based version of transport (file xc/lib/xtrans/Xtranslcl.c, my copy is visible as http://phobos.illtel.denver.co.us/pub/X11R6.3/xc/lib/xtrans/Xtranslcl.c). I can imagine that Solaris in its weirdness managed to use STREAMS-based operations on the server and BSD fd-passing emulation on the client, but that is just a wild guess. If you want to check that, keep in mind that Solaris' idea of "BSD" is derived from the need of SunOS 4.x.x compatibility, so it's 4.3, not 4.4. AF_UNIX sockets handling is in xc/lib/xtrans/Xtranssock.c (http://phobos.illtel.denver.co.us/pub/X11R6.3/xc/lib/xtrans/Xtranssock.c), and it looks like regular socket() / bind() / listen() / accept() for both TCP and AF_UNIX. > Any light you can shed on this will be appreciated. In the meantime, I'm going > to start exploring UNIX-domain sockets, because they have the behavior I want. They should work "normal" way, but just 3 days ago I have submitted a PR for a nasty bug that is triggered in some situations while doing fd-passing through AF_UNIX sockets (PR kern/4345, http://www.freebsd.org/cgi/query-pr.cgi?pr=4345), so I don't recommend to use fd-passing through AF_UNIX sockets on versions that can be crashed by the test that I have included in PR. Regular socket() / bind() / listen() / accept() model doesn't appear to have any problems. > But I vaguely remember hearing that the Solaris method is faster (well, at least > for Solaris :). In Solaris a lot of BSD-compatible things are implemented at the top of STREAMS, and therefore are even slower than STREAMS themselves. I have heard about STREAMS implementations for FreeBSD and Linux. IMHO they aren't in "regular" kernels of either because they don't fit into BSD-based system and encourage programmer to use the model, inefficient enough even on real SVR4, and more so in the port to BSD. SVR4 developers claim that STREAMS provide a lot of useful things for them, although BSD already had most of them implemented BSD-native way at the time of STREAMS "invention", and only the base functionality of STREAMS (pushable modules) doesn't have anything matching in BSD. Probably it's a good thing because of the overhead introduced by it and usefullness only in the situation when everything can use it (and therefore has this overhead). BTW, threads support is another thing where Solaris is too proud of its performance while other systems run circles around it with normal processes using better-designed context switches. So optimization of user-space program's interaction with the kernel that will work well on Solaris most likely can't be applied to any BSD-based system, especially if STREAMS-specific vs. BSD-specific operations, threads vs. processes, etc are involved. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970823025520.24692B-100000>