Date: Mon, 14 Dec 1998 06:55:16 +0100 (CET) From: List User <listuser@netspace.net.au> To: freebsd-current@FreeBSD.ORG Message-ID: <199812140555.GAA08425@doorway.home.lan>
next in thread | raw e-mail | index | archive | help
Newsgroups: freebsd.current
Path: root
From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: inetd: realloc/free bug
Received: (from dillon@localhost)
by apollo.backplane.com (8.9.1/8.9.1) id SAA07846;
Sun, 13 Dec 1998 18:08:31 -0800 (PST)
(envelope-from dillon)
To: Terry Lambert <tlambert>
Sender: owner-freebsd-current@FreeBSD.ORG
Organization: Private News Host
Precedence: bulk
Message-ID: <199812140208.SAA07846@apollo.backplane.com>
References: <199812132244.PAA10383@usr09.primenet.com>
Delivered-To: vmailer-current@freebsd.org
X-Uidl: 286bceb955549236b6e1d1cad241ea38
X-Loop: FreeBSD.ORG
Cc: archie, jwd, freebsd-current
Date: Mon, 14 Dec 1998 02:08:31 GMT
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
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?199812140555.GAA08425>