Date: Sun, 13 Dec 1998 18:08:31 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: archie@whistle.com, jwd@unx.sas.com, freebsd-current@FreeBSD.ORG Subject: Re: inetd: realloc/free bug Message-ID: <199812140208.SAA07846@apollo.backplane.com> References: <199812132244.PAA10383@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think there's some confusion here: The reason there is a timeout on
the select has nothing to do with signals interrupting system calls. We
don't care about that case - it's irrelevant. The only reason there is
a timeout on the select is to handle the case where a signal occurs
just *BEFORE* select() is entered where the signal function adds a
file descriptor to the mask set. If this case occurs, the select() will
wind up waiting on a mask set that does not contain the new descriptor
thus possibly resulting in an infinite wait. That is the *SOLE REASON*
why there is a timeout on the select.
As I have said repeatedly: If someone does a read of the code and can
guarentee that none of the signal functions *add* a descriptor to the
mask set, we can remove the timeout entirely.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
:> :> If you put a time limit on select(), it doesn't matter if there is a
:> :> race condition there. How does select() cause a signal to be missed ?
:> :
:> :Well, sure.. :-) but then you don't service signals in real time
:> :and spend extra cycles timing out all the time.
:>
:> You do serve signals in real time... the signals are *unmasked* during
:> the select() :-) ... the race condition is that the unmasked signal may
:> cause the descriptor set to be changed just prior to the select() call,
:> causing select() to wait forever. The timeout on the select() handles
:> the race condition without effecting the realtime delivery of signals.
:
:You should just use siginterrupt(3) to make sure select restarts, and be
:done with it.
:
:If you need to interrupt the select after setting system call restart
:behaviour, then use a longjmp from the signal handler after setting a
:volatile flag so that the flag can be tested in the "else" case of
:the setjmp() call.
:
:If the call is restarted, you don't have to worry about the timer, it
:will do the right thing, and you won't get an EINTR that you con't know
:how to handle the masks around.
:
:If you don't like siginterrupt(3), and want to use the non-Berkeley
:signal mechanisms for setting call restart behaviour, then be my
:guest and write 30 or 40 lines of POSIX expecting code instead.
:
:The siginterrupt(2) system call first appeared in BSD 4.1c; the
:current code uses POSIX sigaction(2); someone might want to correct
:the siginterrupt(3) man page...
:
:
: Terry Lambert
: terry@lambert.org
:---
:Any opinions in this posting are my own and not those of my present
:or previous employers.
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-current" in the body of the message
:
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?199812140208.SAA07846>