Date: Fri, 25 Jan 2002 14:25:53 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <3C51DB71.5CE2010F@mindspring.com> References: <Pine.SUN.3.91.1020125164325.24428A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
> > Can't you handle this with a user space glue trampoline,
> > with signals being delivered to the process *always*,
> > but delivered to the user's code based on user space
> > masking/trapping registrations with the signal code?
>
> It's not signal delivery that is the problem, it is the
> process signal mask. Signals are always delivered to
> the threads library signal handler which then delivers
> them to the correct thread. But the threads library
> keeps track of the process signal mask (as well as
> installed signal handlers, sa_masks, etc) and can't have
> the application change them with getcontext/setcontext
> (since the signal mask is part of ucontext_t).
I understand this.
I was suggesting moving the process signal masking into
user space code, instead, so that there was not system
call requirement for manipulating the mask.
In other words, always deliver all signals to user space,
and then have a user space signal dispatcher that looks
at the user space mask, and decides whether to queue a
suspended signal deliver, blackhole a blocked one, or
invoke a handler.
I guess my VMS reference was too obscure. 8-). They did
not have signals, per se, in the OS, and so had to use
their event delivery mechanisms to emulate them. So there
was *only* the user space signal dispatcher.
> > The FPU usage is problematic, but is also resolvable, as a
> > tools issue.
> >
> > Specifically, if an ELF section were generated whenever
> > the compiler generated FPU code (let's call this section
> > "flags", for the sake of argument), then the flag "FPU=1"
> > could be set there.
>
> [ ... ]
>
> Interesting. I think we only care about FPU state
> during signal deliver and preemptions though, and in
> that case, the kernel can just pass us the "FPU used"
> flag and/or "FPU format" along with the interrupted
> context. When the context is resumed, it can look
> at the flag/format and see whether it needs to restore
> the FPU state.
I think this ignores intentional non-signal use of the
{s|g}etcontext(), mixed with signal use. I fear that it
will not be possible to ignore the state in the case of
a setcontext() following a getcontext without the "FPU
used" flag, after a later getcontext with the "FPU used"
flag.
If you can see a way to make this work -- an attempt to
setcontext() with the FPU state a context from a prior
getcontext() without -- I'd like to understand it.
Maybe I'm implying a symmetry that I shouldn't be?
-- 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?3C51DB71.5CE2010F>