From owner-freebsd-hackers Sat May 10 00:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA25213 for hackers-outgoing; Sat, 10 May 1997 00:57:06 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25208 for ; Sat, 10 May 1997 00:57:03 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id BAA26656; Sat, 10 May 1997 01:00:21 -0700 Date: Sat, 10 May 1997 01:00:21 -0700 (PDT) From: Alex Belits To: Joerg Wunsch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: socketpair() In-Reply-To: <19970510085902.LT52179@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 10 May 1997, J Wunsch wrote: > > What are the advantages (if any) of using socketpair(PF_LOCAL, ... > > as compared with pipe()? > > socketpair() is guranteed to create a bidirectional connection. > pipe() incidentally does this in 4.4BSD, and i think also in FreeBSD > (which is now different from 4.4BSD since it has John D's revamped > pipe code), i think also in SVR4. > > pipe() is way faster in FreeBSD, since it avoids the overhead from the > network layers. I don't think that PF_LOCAL implements OOB data, so > you don't lose anything by using pipe() except portability when it > comes to a bidirectional connection. Actually no sane person will use pipe() and expect bidirectional connection to be created in any portable program -- all standards and most of implementations have unidirectional pipes. And having pipe() using AF_LOCAL/AF_UNIX is stupid in the first place unless the whole system is STREAMS-based. The advantage of BSD pipe() is lost on those systems, and STREAMS offer other features that may make program faster if it will utilize them. Fast pipes and slow pipes/sockets with STREAMS produce two mutually exclusive ways to optimize a program (thanks, AT&T! :-\), just like processes with fast context switching and threads with slow context switching for processes (thanks, Sun and M$! :-\). -- Alex