From owner-freebsd-hackers  Wed Jan 31 00:04:01 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id AAA28630
          for hackers-outgoing; Wed, 31 Jan 1996 00:04:01 -0800 (PST)
Received: from warrane.connect.com.au (warrane.connect.com.au [192.189.54.33])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA28567
          for <hackers@freebsd.org>; Wed, 31 Jan 1996 00:03:11 -0800 (PST)
Received: (from root@localhost) by warrane.connect.com.au with UUCP id SAA15697
  (8.6.12/IDA-1.6); Wed, 31 Jan 1996 18:56:09 +1100
Received: by rex.sfe.com.au id AA28625
  (5.67a/IDA-1.5); Wed, 31 Jan 1996 18:49:01 +1100
From: Paul Hatchman <paul@sfe.com.au>
Message-Id: <199601310749.AA28625@rex.sfe.com.au>
Subject: Re: signal masks and select
To: leisner@sdsp.mc.xerox.com (Marty Leisner)
Date: Wed, 31 Jan 1996 18:49:00 +1100 (EST)
Cc: linux-kernel@vger.rutgers.edu, hackers@freebsd.org
In-Reply-To: <9601301744.AA29546@gnu.mc.xerox.com> from "Marty Leisner" at Jan 30, 96 09:44:51 am
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

> 
> 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
--------------------------------------------------------------------------------