Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jan 2002 14:30:23 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Nate Williams <nate@yogotech.com>
Cc:        Daniel Eischen <eischen@pcnet1.pcnet.com>, Bruce Evans <bde@zeta.org.au>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG
Subject:   Re: Request for review: getcontext, setcontext, etc
Message-ID:  <3C3F677F.5F952FBE@mindspring.com>
References:  <3C3F500E.A1736EC0@mindspring.com> <Pine.SUN.3.91.1020111160903.19846A-100000@pcnet1.pcnet.com> <15423.22424.600588.40210@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Nate Williams wrote:
> > Just to clarify about how POSIX defines signals being delivered to
> > threads though...
> >
> >   SIGILL, SIGBUS, SIGFPE, etc, are synchronous signals and should
> >   be delivered to the current thread (as long as they are unmasked).
> >
> > I admit to being somewhat confused by what Bruce wrote also, but
> > if we can comply with the above, that would be a good thing.
> 
> This is exactly what I'm trying to get clarified.
> 
> How can we accomplish it so that these signals/exceptions are properly
> reported within the correct context. :) :)

Read that again.  It doesn't clarify a damn thing.  All it says
is that when they are synchronously delivered, they need to be
delivered to the current thread.

It says nothing about whether the synchronicity is in regards
to when the condition is raised, vs. when an exception actually
occurs.

Thus one thread could cause a fault that remains unreported
until the next thread in a different context causes an FPU
exaception, and POSIX would dictate that the fault be delivered
synchronously to the context where the exception was raised.

The problem is the "one instruction behind" that the idiot
hardware designers expected to be fixed by software, rather
than by non-astonishing hardware.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3F677F.5F952FBE>