From owner-freebsd-hackers Sun Nov 8 17:16:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17273 for freebsd-hackers-outgoing; Sun, 8 Nov 1998 17:16:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17266 for ; Sun, 8 Nov 1998 17:16:21 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id RAA08621; Sun, 8 Nov 1998 17:10:10 -0800 (PST) (envelope-from marcs@znep.com) Date: Sun, 8 Nov 1998 17:10:10 -0800 (PST) From: Marc Slemko To: Brian Somers cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bind()/listen() race In-Reply-To: <199811082334.XAA06518@woof.lan.awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 8 Nov 1998, Brian Somers wrote: > The code says something like: > > if (bind(blah) < 0) { > /* we're happy to be the client */ > if (connect(blah) < 0) { > socket is bound without a listen ! > } > } else if (listen(blah) < 0) { > oops ! > } > > The sockaddrs are local domain sockets used by ppp in multilink mode. > Whoever gets to be the server will survive. The other ppp will > become the client, pass a file descriptor to the server and hang > around holding the session 'till the other ppp kills it. > > However, if the two ppps get unlucky, one bind()s and the second > fails then tries to connect() and fails 'cos the server hasn't > listen()ed yet. This is bad news. > > The only way I can see around it - given that I can't sleep() in ppp > without screwing up with other timing issues - is to detect the error > and do a 1 second timeout, and try again then. This is a nasty thing > to have to do.... I'd prefer an atomic bind()/listen() facility.... No, an atomic bind/listen isn't the solution, you simply need some form of synchronization between the processes. For example, you could use a lockfile and require a write lock arouncd the bind and listen. Unfortunately, inter process synchronization is more of a pain than intra process synchronization. If you used a lock file on disk with the server pid, you could also avoid mistakenly thinking that something else listening on the port is the server. You suggestion is possible as a workaround, and is probably the easiest fix. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message