Date: Wed, 31 Jan 1996 18:49:00 +1100 (EST) From: Paul Hatchman <paul@sfe.com.au> To: leisner@sdsp.mc.xerox.com (Marty Leisner) Cc: linux-kernel@vger.rutgers.edu, hackers@freebsd.org Subject: Re: signal masks and select Message-ID: <199601310749.AA28625@rex.sfe.com.au> In-Reply-To: <9601301744.AA29546@gnu.mc.xerox.com> from "Marty Leisner" at Jan 30, 96 09:44:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> Select seems to have a well know problem...
>
> If the idea is to block on select and wait for a signal to kick you out,
> there's a problem...
>
> if you implement code:
>
> set_sigmask(unblock desired signals)
> select(...)
>
> you have a small window where the signal could sneak through and won't
> kick you out of select...so the solution is select can't block forever
> in select (so you have to select for a limited period and poll to see
> if the signal snuck in...)
>
> Is there any interest into making a select call in the kernel with
> a new signal mask...so the above code segment becomes atomic
> (but if you use it, it's not portable to other Unixes without this
> enhancement...)
>
> Comments?
This can be "solved" by using setjmp/longjmp with select.
ie
if (setjmp (env, 1) == 0)
{
set_sigmask(unblock desired signals)
select(...)
}
and your signal handler does a longjmp (env)
There are drawbacks to this.. If you want to unblock signals outside of the
select, you must keep extra state information around, so that the signal handler
knows whether to do a normal return or a longjmp.
May not be elegant, but it is surely better than using non portable methods.
Actually is this truely portable? Will all unicies support longjmp from a
signal handler?
- Paul
--------------------------------------------------------------------------------
Paul Hatchman, | <this line intentionally left blank>
Project Leader, | paul@sfe.com.au
Sydney Futures Exchange, Australia | Tel: +61 2 2560567
--------------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601310749.AA28625>