Date: Mon, 28 Sep 1998 21:56:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gram@cdsec.com (Graham Wheeler) Cc: grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: The inetd realloc problem: an observation Message-ID: <199809282156.OAA07483@usr04.primenet.com> In-Reply-To: <199809280957.LAA11960@cdsec.com> from "Graham Wheeler" at Sep 28, 98 11:57:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
> So far it seems to be working fine. My approach was not as sophisticated as
> the one suggested by others (writing values into a pipe). I just changed
> each handler to set a volatile int variable, modified the main select() to
> use a 60 second timeout, and before the select, did a:
>
> while (any signal handler flag set)
> {
> if (sigchld_flag) { sigchld_flag = 0; do_old_sigchld_handler(); }
> ...
> }
>
> It may be possible that this is vulnerable to race conditions, but thus
> far it has been working fine.
You need to set your system calls to restart automatically to avoid
a select bit set race. See sigaction() if you are using POSIX style
signals, and siginterrupt if you aren't. Call restart is about the
only way to go in a user space threads implementation.
If you don't have call restart, then you don't need the timeout
(select will return -1 with an errno of EINTR). If you do this,
make sure you do *not* need to get "exceptional condition" notification
via select, since exceptional conditions, unlike "data available"
notifications, are *not* necessarily persistant.
Finally, if you are using X, then you will need to treat XPending()
as a "select is true on the X server's fd"; this is because the
library will cache multiple XEvents, and this can shoot you in the
foot (the programmer who wrote the Microsoft Windows Telnet program
was too dumb to know that Windows events follow the same rules,
which is why it can get "lagged").
> Perhaps it would be better to increment/decrement the flags, rather than
> set/clear them...?
No.
Signals are persistent conditions, and it is incorrect to treat
them as events. You may get a single delivery instance for multiple
trigger events (e.g., one SIGCHLD for multiple child process exits).
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809282156.OAA07483>