Date: Sat, 12 Dec 1998 17:58:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Peter Edwards <peter.edwards@isocor.ie>, Archie Cobbs <archie@whistle.com>, freebsd-current@FreeBSD.ORG Subject: Re: inetd: realloc/free bug Message-ID: <199812130158.RAA14315@apollo.backplane.com> References: <199812130138.RAA22963@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:It also has the downside of keeping inetd "active", so it can't
:be totally swapped out if it's not in use. This might be a bit
:of a concern to some folks, like those who run FreeBSD on their
:laptops. Your implementation is also more syscall intensive than
:some of the alternatives.
We may be able to remove the timeout from the select(), but someone
else is going to have to go through the code (as I indicated earlier)
to determine that this is the case before removing the timeout.
:Your patch also doesn't eliminate all the race conditions. When
:a signal handler is invoked, it blocks reception of the signal that
:triggered it, but not the reception of other signals, so it is possible
Sure it does. Look at the code. Line 410 or so of inetd.c
:Oh yeah, there is another race condition that I've never seen mentioned.
:In the case of TCP services where we do something like
: ctrl = accept(...);
: pid = fork();
: if (pid == 0) {
: fiddle with fds
: exec(...);
: }
: close(ctrl);
:there is a problem if the child process runs, writes a bunch of data
:to the socket and exits before the parent process executes the close().
:If this happens, the close() in the parent can hang for an indefinite
:period of time, until the client consumes the buffered data on the socket.
:I fixed this in BIND 4.x a few years ago using a pipe to synchronize
I'm not sure I follow. close() on a socket descriptor does not block.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812130158.RAA14315>