cfoughty@digi.lonestar.org (Cy Foughty) (06/08/91)
What are the differences between a regular pipe and a named pipe? Which type of pipe is faster and by how much? Which is faster, a named pipe or a message queue? Does a named pipe always go to disk or only when the allocated memory is exhausted? Finally, please send me any additional comments, hints, or suggestions concerning Interprocess Communications. I been using ALL the different IPC mechanisms for years but there are a few lingering questions. -- Cy Foughty DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 Work:214.519.4237 La Casa:214.578.8837 Don't compromise your compromises.
torek@elf.ee.lbl.gov (Chris Torek) (06/09/91)
In article <1991Jun7.195953.27744@digi.lonestar.org> cfoughty@digi.lonestar.org (Cy Foughty) writes: >What are the differences between a regular pipe and a named pipe? The main difference is that one has a name and one does not. The only other substantive difference is that a regular pipe can only be `half- open' when it is shutting down (either all readers or all writers have closed their descriptors, and none will ever gain a new one), while a named pipe is half-open at the beginning (only a reader, or only a writer, exists). This makes named pipes more complicated. >Which type of pipe is faster and by how much? >Which is faster, a named pipe or a message queue? >Does a named pipe always go to disk or only when the allocated >memory is exhausted? All of these are implementation-dependent. The only way to find out is to try it on each implementation (or read the implementation's source, though source-based performance analysis is quite a trick). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
zfgo01@hgo7.hou.amoco.com (F. G. Oakes) (06/09/91)
cfoughty@digi.lonestar.org (Cy Foughty) writes: > What are the differences between a regular pipe and a > named pipe? > Which type of pipe is faster and by how much? > Which is faster, a named pipe or a message queue? > Does a named pipe always go to disk or only when the allocated > memory is exhausted? > Finally, please send me any additional comments, hints, or > suggestions concerning Interprocess Communications. I been > using ALL the different IPC mechanisms for years but there > are a few lingering questions. I don't mean to offend, but I think some of this would be obvious if you RTM. As to which is faster--depends on your CPU, the version of UNIX you're using, etc. There are a number of good references on the design, structure, and internals of the UNIX operating system that describe this very well. I'd recommend them as supplemental reading--not light, but enlightening. As far as IPC, I've found the docmentation, included with the operating system (SVR5.3.X and SVR4.0) to adequate for me. -- ============================================================================ zfgo01@hgo7.hou.amoco.com (Glen Oakes)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/10/91)
In article <14079@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: > In article <1991Jun7.195953.27744@digi.lonestar.org> > cfoughty@digi.lonestar.org (Cy Foughty) writes: > >What are the differences between a regular pipe and a named pipe? > The main difference is that one has a name and one does not. Pipes are part of UNIX. Named pipes aren't. Named pipes appear in most (all?) System V releases and some BSD-derived releases, notably SunOS and Ultrix (where they are also called ``ports''). Named pipes are formalized by POSIX, with a slightly different behavior from that in any existing system. Pipes in POSIX are defined as special cases of named pipes. Pipes under Ultrix are not special cases of named pipes; they're implemented separately. Pipes under straight BSD are special cases of UNIX-domain sockets. (You can see most of this from the output of my pff program... ah, shaddap, Dan.) Basically, pipes work the same way everywhere, and named pipes don't. The name part of named pipes is their least portable aspect. Never use them in a long-lived program if you can use any other communications mechanism. > >Which type of pipe is faster and by how much? > >Which is faster, a named pipe or a message queue? > >Does a named pipe always go to disk or only when the allocated > >memory is exhausted? > All of these are implementation-dependent. On systems where pipes and named pipes use the same mechanism, neither one is faster (obviously). Under Ultrix they appear to run at the same speed anyway. Message queues are uniformly slower in my tests. On systems where named pipes are implemented in terms of sockets, they don't go to disk; under at least some versions of Ultrix they do go to disk. Basically, what Chris said. ---Dan
boyd@prl.dec.com (Boyd Roberts) (06/10/91)
In article <1991Jun7.195953.27744@digi.lonestar.org>, cfoughty@digi.lonestar.org (Cy Foughty) writes: > Which is faster, a named pipe or a message queue? > Are, therein lies a tale. A few years back I was asked this question for vanilla System V.2.2 and found some interesting things about message queues (gag). In the benchmark it turned out that pipes used more CPU time, but got that amount of CPU in (about) the same amount of real time. Whereas message queues took less CPU time, but _the real time was double the CPU time_. Clearly the pipe was faster, but more CPU intensive. But, I was worried about why the message queues took so much real time. So, after reading the source I realised that the boneheads who'd implemented messages queues only woke up queue readers _every once in a while_. Hence the anomalous amount of real time. Readers weren't woken up when the data was ready, but at some later time! Moral: System V IPC sucks. Use pipes. The file-system is your friend. Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
jfh@rpp386.cactus.org (John F Haugh II) (06/10/91)
In article <14192:Jun923:16:0791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Pipes are part of UNIX. Named pipes aren't. Named pipes appear in most >(all?) System V releases and some BSD-derived releases, notably SunOS >and Ultrix (where they are also called ``ports''). Named pipes are in every AT&T-derived System V release given that they were part of 5.0. They were also in 4.0 [ which was never generally released ] and they were even in System III. [ tho I lack a set of "genuine Bell" manuals to back that up with ... ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
cfoughty@digi.lonestar.org (Cy Foughty) (06/10/91)
In article <zfgo01.676423337@hgo7> zfgo01@hgo7.hou.amoco.com (F. G. Oakes) writes: >cfoughty@digi.lonestar.org (Cy Foughty) writes: > > >> What are the differences between a regular pipe and a >> named pipe? > >> Which type of pipe is faster and by how much? > >> Which is faster, a named pipe or a message queue? > >> Does a named pipe always go to disk or only when the allocated >> memory is exhausted? > >> Finally, please send me any additional comments, hints, or >> suggestions concerning Interprocess Communications. I been >> using ALL the different IPC mechanisms for years but there >> are a few lingering questions. > >I don't mean to offend, but I think some of this would be obvious if you RTM. > >As to which is faster--depends on your CPU, the version of UNIX you're using, >etc. > >There are a number of good references on the design, structure, and internals >of the UNIX operating system that describe this very well. I'd recommend them >as supplemental reading--not light, but enlightening. > >As far as IPC, I've found the docmentation, included with the operating >system (SVR5.3.X and SVR4.0) to adequate for me. >-- >============================================================================ >zfgo01@hgo7.hou.amoco.com (Glen Oakes) Unfortunately Unix manuals are a joke at best. Not everything works as advertised. Hardly any books/manuals include live working examples. I also don't need "adequate" documentation, I need answers quick. I've a lot of work to perform. -- Cy Foughty DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 Work:214.519.4237 La Casa:214.578.8837 Don't compromise your compromises.
ron@eatdust (Ron Schweikert) (06/11/91)
In article <1991Jun10.143256.29982@digi.lonestar.org> cfoughty@digi.lonestar.org (Cy Foughty) writes: >In article <zfgo01.676423337@hgo7> zfgo01@hgo7.hou.amoco.com (F. G. Oakes) writes: >>cfoughty@digi.lonestar.org (Cy Foughty) writes: (lots of stuff deleted about named pipes vs. regular ones, asking for info on IPC etc..) Reply was some information, plus recommendation to dig into the manuals. Response was... > >Unfortunately Unix manuals are a joke at best. Not everything works as >advertised. Hardly any books/manuals include live working examples. >I also don't need "adequate" documentation, I need answers quick. I've a >lot of work to perform. >-- >Cy Foughty >DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 >Work:214.519.4237 La Casa:214.578.8837 >Don't compromise your compromises. Well, excuuuuuuuse us! We'll try to monitor the net so we can jump on your questions quickly in the future (Or did I take your response wrong?) The admonition to check the manuals (RTM or RTFM) plays along the same lines as "If a man is hungry, is it better to give him a fish, or teach him how to fish?" The net *is* a great place for fast answers, but your response that you don't need "adequate" documentation, but rather "fast answers" because you have "a lot of work to perform" is rather condescending. Don't you think we all have work to perform too?? I apologize publicly if I misinterpreted your response, but it didn't have a :-) by it...
gwc@root.co.uk (Geoff Clare) (06/11/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Basically, pipes work the same way everywhere, and named pipes don't. >The name part of named pipes is their least portable aspect. Never use >them in a long-lived program if you can use any other communications >mechanism. Apart from the fact that Dan obviously didn't mean what he wrote here ("any other communications mechanism" would include a mechanism specific to one system, and therefore totally non-portable), I think he is doing named pipes an injustice. I would say that named pipes are the most portable inter-process communications mechanism after plain files and unnamed pipes. They are certainly more portable than message queues or shared memory. -- Geoff Clare <gwc@root.co.uk> (Dumb American mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
les@chinet.chi.il.us (Leslie Mikesell) (06/11/91)
In article <14192:Jun923:16:0791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Pipes are part of UNIX. Named pipes aren't. And I thought that only AT&T could decide what was a part of UNIX. Hmmm. >Named pipes are >formalized by POSIX, with a slightly different behavior from that in any >existing system. Can you elaborate on these differences? >Basically, pipes work the same way everywhere, and named pipes don't. >The name part of named pipes is their least portable aspect. Never use >them in a long-lived program if you can use any other communications >mechanism. Under SysV they seem to be the only thing that works across RFS without special programming. And in general they are the only IPC that can be used directly in shell scripts. Are you predicting that this is going to go away in future releases? Les Mikesell les@chinet.chi.il.us
cfoughty@digi.lonestar.org (Cy Foughty) (06/11/91)
In article <1991Jun10.174828.27518@cherokee.uswest.com> ron@eatdust (Ron Schweikert) writes: >In article <1991Jun10.143256.29982@digi.lonestar.org> cfoughty@digi.lonestar.org (Cy Foughty) writes: >>In article <zfgo01.676423337@hgo7> zfgo01@hgo7.hou.amoco.com (F. G. Oakes) writes: >>>cfoughty@digi.lonestar.org (Cy Foughty) writes: > >(lots of stuff deleted about named pipes vs. regular ones, asking for info >on IPC etc..) Reply was some information, plus recommendation to dig into >the manuals. Response was... > >> >>Unfortunately Unix manuals are a joke at best. Not everything works as >>advertised. Hardly any books/manuals include live working examples. >>I also don't need "adequate" documentation, I need answers quick. I've a >>lot of work to perform. >>-- >>Cy Foughty >>DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 >>Work:214.519.4237 La Casa:214.578.8837 >>Don't compromise your compromises. > >Well, excuuuuuuuse us! We'll try to monitor the net so we can jump on your >questions quickly in the future (Or did I take your response wrong?) > >The admonition to check the manuals (RTM or RTFM) plays along the same lines >as "If a man is hungry, is it better to give him a fish, or teach him how to >fish?" > >The net *is* a great place for fast answers, but your response that you don't >need "adequate" documentation, but rather "fast answers" because you have "a >lot of work to perform" is rather condescending. Don't you think we all have >work to perform too?? > >I apologize publicly if I misinterpreted your response, but it didn't have >a :-) by it... I did forget ;-) by it. Seriously, Unix manuals are not very verbose. I did sound condescending, and for that I apologize. But, I always go to the net as a last resort AFTER I've RTM several times. The replies have been very helpful. I also couldn't find my "Bach" book. ;-) -- Cy Foughty DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 Work:214.519.4237 La Casa:214.578.8837 Don't compromise your compromises.
chip@tct.com (Chip Salzenberg) (06/12/91)
According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein): >Pipes are part of UNIX. Named pipes aren't. The second quoted sentence is vacuous. There is no longer any one OS that can be called "UNIX". >Basically, pipes work the same way everywhere, and named pipes don't. Granted. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> perl -e 'sub do { print "extinct!\n"; } do do()'
ronnie@mindcraft.com (Ronnie Kon) (06/12/91)
In article <1991Jun10.174828.27518@cherokee.uswest.com> ron@eatdust (Ron Schweikert) writes: >In article <1991Jun10.143256.29982@digi.lonestar.org> cfoughty@digi.lonestar.org (Cy Foughty) writes: >>In article <zfgo01.676423337@hgo7> zfgo01@hgo7.hou.amoco.com (F. G. Oakes) writes: >>>cfoughty@digi.lonestar.org (Cy Foughty) writes: > >The net *is* a great place for fast answers, but your response that you don't >need "adequate" documentation, but rather "fast answers" because you have "a >lot of work to perform" is rather condescending. Don't you think we all have >work to perform too?? I know I do. That's why I spend so much of my life reading news. :-) Ronnie -- ------------------------------------------------------------------------------- Ronnie B. Kon | "Was it a millionaire who said kon@groundfog.stanford.edu | 'Imagine no possessions'?" ...!{decwrl,ames}!mindcrf!ronnie | -- Elvis Costello -------------------------------------------------------------------------------
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/13/91)
In article <2736@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Basically, pipes work the same way everywhere, and named pipes don't. > >The name part of named pipes is their least portable aspect. Never use > >them in a long-lived program if you can use any other communications > >mechanism. > Apart from the fact that Dan obviously didn't mean what he wrote here > ("any other communications mechanism" would include a mechanism specific > to one system, and therefore totally non-portable), I meant what I wrote. A program which supports message queues and UNIX-domain sockets will work correctly on far more machines than a program which supports named pipes. In fact, a program which does anything with named pipes that couldn't be done with pipes is almost certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/13/91)
In article <28552162.546B@tct.com> chip@tct.com (Chip Salzenberg) writes: > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein): > >Pipes are part of UNIX. Named pipes aren't. > The second quoted sentence is vacuous. There is no longer any one OS > that can be called "UNIX". Pipes have been part of UNIX since before its first widespread implementation. They're supported by all UNIX systems; a system without pipes cannot be UNIX. In contrast, a system doesn't have to support named pipes to be UNIX. Lots of UNIX systems didn't---and still don't---have named pipes. So named pipes aren't part of UNIX. They're just an add-on, a feature which happens to be supported in similar ways by several vendors but isn't available everywhere. ---Dan
barts@cyber.Eng.Sun.COM (Bart Smaalders barts@cyber.Eng) (06/13/91)
The key difference between regular pipes and named pipes is that named pipes can support communication between unrelated processes. Since one cannot get unrelated processes to communicate using regular pipes, it is trivially easy to construct an example where the statement: In fact, a program which does anything with named pipes that couldn't be done with pipes is almost certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. is false, if we allow the word program to mean programS. If all that is desired is communication between related programs, use the pipe call. Named pipes are a useful way of performing communication between processes. It fits in well with X programs, since named pipes support select. This is in distinct contrast to other SV IPC paradigms. - Bart Smaalders (barts@Eng.sun.com)
les@chinet.chi.il.us (Leslie Mikesell) (06/13/91)
In article <25101:Jun1217:29:0291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >I meant what I wrote. A program which supports message queues and >UNIX-domain sockets will work correctly on far more machines than a >program which supports named pipes. In fact, a program which does >anything with named pipes that couldn't be done with pipes is almost >certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. Does "anything" include open()? And by more machines, do you mean more types of machine or more existing machines? I'd guess that 386's running SysVr3 or Xenix are the biggest chunk of the unix market right now and they won't have sockets unless they come with an add-on TCP/IP package. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (06/13/91)
In article <25293:Jun1217:36:2291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In contrast, a system doesn't have to support named pipes to be UNIX. >Lots of UNIX systems didn't---and still don't---have named pipes. So >named pipes aren't part of UNIX. They're just an add-on, a feature which >happens to be supported in similar ways by several vendors but isn't >available everywhere. In what way is this different from sockets? Or any other IPC mechanism besides plain files and signals that doesn't require a common parent to set things up? Les Mikesell les@chinet.chi.il.us
woods@eci386.uucp (Greg A. Woods) (06/14/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > In article <2736@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes: > > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > >Basically, pipes work the same way everywhere, and named pipes don't. > > >The name part of named pipes is their least portable aspect. Never use > > >them in a long-lived program if you can use any other communications > > >mechanism. > > > > Apart from the fact that Dan obviously didn't mean what he wrote here > > ("any other communications mechanism" would include a mechanism specific > > to one system, and therefore totally non-portable), > > I meant what I wrote. A program which supports message queues and > UNIX-domain sockets will work correctly on far more machines than a > program which supports named pipes. In fact, a program which does > anything with named pipes that couldn't be done with pipes is almost > certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. GRRR! You should really read some market data Dan. There are probably several million more "machines" out there running with Named Pipes and no Sockets than there are the other way 'round. As others have said, they were in UNIX (i.e. the trademarked one from AT&T) since a long time ago, and work more portably on any versions of UNIX derived from the "real" AT&T version than any other IPC mechanism available on the same machines. You can blame whoever you want for not keeping BSD UNIX in line with AT&T's versions. They seem to have split the tree quite early, and not only were they not interested in updating their license, but were not even interested in matching their functionality, if only for portability reasons.... On the other hand, AT&T have endeavored to include some of the more coherent features of BSD in current releases, even if they did go a bit over-board with r4! As for the future, "real" UNIX will have Named Pipes for quite some time, only they call them FIFO's now. In case you missed it, please see mkfifo(1m) and mkfifo(3c) in the SysVr4 documentation. According to read(2) from the same documentation, FIFO's have *exactly* the same semantics as pipes created by pipe(2), as I believe they "always" have. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
jfh@rpp386.cactus.org (John F Haugh II) (06/14/91)
In article <1991Jun13.143802.3600@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <25101:Jun1217:29:0291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >>I meant what I wrote. A program which supports message queues and >>UNIX-domain sockets will work correctly on far more machines than a >>program which supports named pipes. In fact, a program which does >>anything with named pipes that couldn't be done with pipes is almost >>certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. > >Does "anything" include open()? And by more machines, do you mean >more types of machine or more existing machines? I'd guess that >386's running SysVr3 or Xenix are the biggest chunk of the unix >market right now and they won't have sockets unless they come with >an add-on TCP/IP package. Dan's statement is pretty much a bunch of nonsense. Since named pipes predate the current variety of message queues [ or at least are no newer than ... ] there are at least as many systems which support named pipes as support System V message queues - and remember than BSD didn't have the same message quees as System V, so screw the issue of BSD sockets. Named pipes can be implemented with a virtual device driver, in fact this is one of the first device drivers I ever wrote, and exactly because I didn't have an IPC mechanism on the platform I was using. Since named pipes can be simulated with a device driver, and since all UNIX's have device drivers, Dan's statement falls flat. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
karish@mindcraft.com (Chuck Karish) (06/15/91)
In article <1991Jun13.184737.6343@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: |brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: || I meant what I wrote. A program which supports message queues and || UNIX-domain sockets will work correctly on far more machines than a || program which supports named pipes. In fact, a program which does || anything with named pipes that couldn't be done with pipes is almost || certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. | |GRRR! You should really read some market data Dan. There are |probably several million more "machines" out there running with Named |Pipes and no Sockets than there are the other way 'round. As far as new UNIX-like systems go, change "more" to "most" systems supporting FIFOs. This includes the current releases of SunOS and ULTRIX. mkfifo() is specified in POSIX.1, so we can expect this interface and support for FIFOs themselves to become universal over the next year or two. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <1991Jun13.143802.3600@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <25101:Jun1217:29:0291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >I meant what I wrote. A program which supports message queues and > >UNIX-domain sockets will work correctly on far more machines than a > >program which supports named pipes. In fact, a program which does > >anything with named pipes that couldn't be done with pipes is almost > >certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. > Does "anything" include open()? Yes. System V, BSD, and POSIX all disagree on the blocking behavior of opening named pipes in various modes, on their behavior with multiple readers and writers, and on the effects of close(). > And by more machines, do you mean > more types of machine or more existing machines? Both. Most types of machines support sockets; most machines support message queues. Most types of machines do not support named pipes. Now that several vendors offer System V-based POSIX systems, you can't even write named pipe code that works on all System V machines. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <1991Jun13.144148.3842@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <25293:Jun1217:36:2291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In contrast, a system doesn't have to support named pipes to be UNIX. > >Lots of UNIX systems didn't---and still don't---have named pipes. So > >named pipes aren't part of UNIX. They're just an add-on, a feature which > >happens to be supported in similar ways by several vendors but isn't > >available everywhere. > In what way is this different from sockets? Or any other IPC mechanism > besides plain files and signals that doesn't require a common parent to > set things up? It's not. As you just observed, the only IPC mechanisms that are part of UNIX are plain files, signals, and pipes. Sockets are part of BSD UNIX; they're not part of UNIX in general. That's why it's such a pain to write some types of code without restricting yourself to one flavor or another of the system. It looks like UNIX in five or ten years will uniformly support sockets and named pipes; at that point my evaluation will change. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <1991Jun13.184737.6343@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > > I meant what I wrote. A program which supports message queues and > > UNIX-domain sockets will work correctly on far more machines than a > > program which supports named pipes. In fact, a program which does > > anything with named pipes that couldn't be done with pipes is almost > > certainly going to fail on one of (A) SunOS; (B) Ultrix; (C) SVR4. > GRRR! You should really read some market data Dan. There are > probably several million more "machines" out there running with Named > Pipes and no Sockets than there are the other way 'round. And there are several hundred thousand more machines out there---in all, supporting many million more users---with either sockets or message queues than there are with named pipes. I didn't say just sockets. > You can blame whoever you want for > not keeping BSD UNIX in line with AT&T's versions. I'm not interested in these religious arguments about whether BSD UNIX is ``real'' UNIX or not. The fact is that ``UNIX'', in any academic or corporate environment, includes the offerings from many vendors, including some pure-BSD as well as pure-AT&T systems. > FIFO's have *exactly* the same > semantics as pipes created by pipe(2), as I believe they "always" have. On some machines, as I outlined near the beginning of this thread, pipes and named pipes do indeed share semantics. On some machines they do not. Anyway, DEC introduced its own changes when it picked up ``ports'' and POSIX introduced several more, so even if pipes and named pipes work the same on one machine, named pipes do not work portably across machines. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <19382@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > Dan's statement is pretty much a bunch of nonsense. Since named > pipes predate the current variety of message queues [ or at least > are no newer than ... ] there are at least as many systems which > support named pipes as support System V message queues - and > remember than BSD didn't have the same message quees as System V, > so screw the issue of BSD sockets. That's the most logical argument I've heard from you in a while, John. Parts of it are even grammatical. Anyway, that last bit makes absolutely no sense: a program supporting named pipes and message queues will miss at least 50,000 pure-BSD mainframes on the Internet alone. To handle them (and their millions of users) a program had better support sockets. As for System V named pipes versus System V message queues, with the advent of POSIX you can't even depend on the old named pipe semantics. Programs which actually want to work should use message queues instead. > Named pipes can be implemented with a virtual device driver, in > fact this is one of the first device drivers I ever wrote, and > exactly because I didn't have an IPC mechanism on the platform > I was using. Since named pipes can be simulated with a device > driver, and since all UNIX's have device drivers, Dan's statement > falls flat. That's ridiculous. The average UNIX sysadmin is not going to muck around with the kernel just so he can run a program that only supports named pipes. Your statements will match reality only if and when every UNIX system in the world has been given a Haugh-approved facelift. ---Dan
peter@ficc.ferranti.com (Peter da Silva) (06/21/91)
In article <1991Jun13.184737.6343@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > GRRR! You should really read some market data Dan. There are > probably several million more "machines" out there running with Named > Pipes and no Sockets than there are the other way 'round. That's why he said "supports message queues and UNIX domain sockets". That is to say: #ifdef BSD ... code for sockets ... #else ... code for message queues ... #endif So he wasn't as insane as he sounded. However, as a user of one of the system that supports neither... but does support named pipes... I do disagree with his conclusion. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (06/21/91)
In article <3048.Jun1423.16.2891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > That's the most logical argument I've heard from you in a while, John. > Parts of it are even grammatical. Tut, tut, Dan. That's not very nice. I have a better argument: System V message queues are an uni-UNIX abomination that create a new name-space for no good reason, and should be avoided whenever possible on political grounds. The single namespace created in the original UNIX design is its greatest strength, and any attempt to confuse things by creating objects that don't appear in it is evil, rude, and should be opposed by all right thinking people. There's glory for you! -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
gwc@root.co.uk (Geoff Clare) (06/21/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Now >that several vendors offer System V-based POSIX systems, you can't even >write named pipe code that works on all System V machines. Yes you can. It's possible to write named pipe code that works on all systems that have named pipes. You just have to be careful to restrict yourself to areas of common behaviour, or allow for the differences in behaviour. For example, the sequence of system calls executed by the following shell command will work on all systems which support named pipes: echo foo > FIFO & echo bar > FIFO & cat FIFO -- Geoff Clare <gwc@root.co.uk> (Dumb American mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273
tg@utstat.uucp (Tom Glinos) (06/21/91)
> >I have a better argument: System V message queues are an uni-UNIX abomination >that create a new name-space for no good reason, and should be avoided whenever >possible on political grounds. The single namespace created in the original >UNIX design is its greatest strength, and any attempt to confuse things by >creating objects that don't appear in it is evil, rude, and should be opposed >by all right thinking people. > >There's glory for you! >-- >Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; The glory of message queues is that they can be amazingly fast. When I looked into this several years ago I found that systems that when a system supports both message queues and named pipes the message queues are orders of magnitudes faster than named pipes. One is therefore tempted to submit oneself to evil!
panos@tigger.Colorado.EDU (Panos Tsirigotis) (06/22/91)
In article <1991Jun21.142246.25245@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: >> >>I have a better argument: System V message queues are an uni-UNIX abomination >>that create a new name-space for no good reason, and should be avoided whenever >>possible on political grounds. The single namespace created in the original >>UNIX design is its greatest strength, and any attempt to confuse things by >>creating objects that don't appear in it is evil, rude, and should be opposed >>by all right thinking people. >> >>There's glory for you! >>-- >>Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; > >The glory of message queues is that they can be amazingly fast. > >When I looked into this several years ago I found that systems >that when a system supports both message queues and named pipes >the message queues are orders of magnitudes faster than named pipes. > >One is therefore tempted to submit oneself to evil! Well, these days this is not always true. I compared message queues with named pipes by having two processes transfer a certain amount of data between them. (the machine is a Sun 3/60 with 16M of memory, running SunOS 4.1). MESSAGE QUEUES: DATA Buffer_Size REAL_TIME SYSTEM_TIME USER_TIME BW (bytes) (bytes) (sec) (sec) (sec) (KB/real_sec) 131072 16 4.62 2.26 0.28 28.37 131072 64 1.24 0.48 0.14 105.70 131072 256 0.38 0.12 0.00 344.93 131072 1024 0.14 0.04 0.02 936.23 131072 2048 0.10 0.00 0.00 1310.72 524288 16 18.60 8.78 0.92 28.19 524288 64 4.92 2.42 0.22 106.56 524288 256 1.44 0.64 0.04 364.09 524288 1024 0.56 0.24 0.00 936.23 524288 2048 0.42 0.26 0.00 1248.30 1048576 16 37.52 17.76 1.86 27.95 1048576 64 9.60 4.40 0.46 109.23 1048576 256 2.76 1.22 0.10 379.92 1048576 1024 1.08 0.54 0.00 970.91 1048576 2048 0.78 0.40 0.00 1344.33 4194304 16 151.26 71.54 7.78 27.73 4194304 64 39.00 18.32 1.82 107.55 4194304 256 11.24 5.06 0.56 373.16 4194304 1024 4.24 1.86 0.08 989.22 4194304 2048 3.16 1.58 0.04 1327.31 ------------------------------------------------------------ NAMED PIPES: DATA Buffer_Size REAL_TIME SYSTEM_TIME USER_TIME BW (bytes) (bytes) (sec) (sec) (sec) (KB/real_sec) 131072 16 5.46 2.52 0.22 24.01 131072 64 1.42 0.72 0.02 92.30 131072 256 0.44 0.22 0.00 297.89 131072 1024 0.16 0.10 0.02 819.18 131072 2048 0.10 0.06 0.00 1310.69 524288 16 21.10 7.86 0.54 24.85 524288 64 5.46 2.62 0.26 96.02 524288 256 1.60 0.60 0.00 327.68 524288 1024 0.58 0.30 0.02 903.94 524288 2048 0.42 0.08 0.02 1248.30 1048576 16 43.22 16.60 0.80 24.26 1048576 64 11.02 4.94 0.30 95.15 1048576 256 3.06 1.36 0.08 342.67 1048576 1024 1.22 0.60 0.02 859.49 1048576 2048 0.76 0.50 0.00 1379.70 4194304 16 173.76 68.76 3.52 24.14 4194304 64 44.18 19.78 1.10 94.94 4194304 256 12.24 5.74 0.26 342.67 4194304 1024 4.30 2.16 0.10 975.42 4194304 2048 3.02 1.16 0.02 1388.84 ------------------------------------------------------------ The above numbers indicate that at least on some OSs message queues and named pipes offer comparable bandwidths. According to the Bach book, the System V R2 implementation of pipes (and named pipes) was using the file system and that may be the reason why named pipes were slower than message queues in the past. Panos -- ----------------------------------------------------------------------------- Panos Tsirigotis, CS grad Computer Science Dept., U. of Colorado @ Boulder, Boulder, CO 80309 Email address: panos@boulder.colorado.edu
peter@ficc.ferranti.com (Peter da Silva) (06/26/91)
In article <1991Jun21.142246.25245@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: > The glory of message queues is that they can be amazingly fast. Ah, an implementation detail. > When I looked into this several years ago I found that systems > that when a system supports both message queues and named pipes > the message queues are orders of magnitudes faster than named pipes. Yes, but that's to be expected. It's the same high priests of evil that did the implementations of both. If they had implemented message queues as special files like named pipes (easy enough to do) they'd be just as fast and we wouldn't have to sacrifice the purity of our bodily fluids to get our work done. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"