From owner-freebsd-hackers  Mon Nov 20 13:44:53 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA11580
          for hackers-outgoing; Mon, 20 Nov 1995 13:44:53 -0800
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA11571
          for <hackers@FreeBSD.org>; Mon, 20 Nov 1995 13:44:48 -0800
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02182; Mon, 20 Nov 1995 14:41:23 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199511202141.OAA02182@phaeton.artisoft.com>
Subject: Re: int type in jmpbuf
To: cimaxp1!jb@werple.net.au (John Birrell)
Date: Mon, 20 Nov 1995 14:41:23 -0700 (MST)
Cc: terry@lambert.org, hackers@FreeBSD.org, jb@cimlogic.com.au
In-Reply-To: <199511202102.IAA16453@werple.net.au> from "John Birrell" at Nov 21, 95 08:06:06 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 765       
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

> > You are assuming that a signal is an event in using it for your scheduler
> > and are in fact screwing up as a result.
> 
> The occurrence of a signal condition gives us an _opportunity_ to check if
> there is another thread that should run instead of the running thread. Async
> I/O gives us the same opportunity. I don't think we are "screwing up as a
> result".

Actually, the occurance of a signal condittion give you the _opportunity_
to set a flag.

Then you check the flag on a blocking call *not* in the signal handler
before actually making the call to decide to do the context switch, and
the problem goes away.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.