From owner-freebsd-hackers Tue Jan 30 09:47:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA10784 for hackers-outgoing; Tue, 30 Jan 1996 09:47:42 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA10779 for ; Tue, 30 Jan 1996 09:47:35 -0800 (PST) Received: from gemini.sdsp.mc.xerox.com ([13.231.132.20]) by alpha.xerox.com with SMTP id <14716(5)>; Tue, 30 Jan 1996 09:44:57 PST Received: from gnu.mc.xerox.com (gnu.sdsp.mc.xerox.com) by gemini.sdsp.mc.xerox.com (4.1/SMI-4.1) id AA29511; Tue, 30 Jan 96 12:44:54 EST Received: by gnu.mc.xerox.com (4.1/SMI-4.1) id AA29546; Tue, 30 Jan 96 12:44:52 EST Message-Id: <9601301744.AA29546@gnu.mc.xerox.com> X-Mailer: exmh version 1.6.4 10/10/95 To: linux-kernel@vger.rutgers.edu, hackers@freebsd.org Subject: signal masks and select Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jan 1996 09:44:51 PST From: "Marty Leisner" 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? marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom (http://www.lpf.org) Any sufficiently advanced technology is indistinguishable from magic Arthur C. Clarke, The Lost Worlds of 2001 -- marty leisner@sdsp.mc.xerox.com Member of the League for Programming Freedom