Date: Wed, 29 Aug 2001 17:32:02 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp> Cc: Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp>, hackers@FreeBSD.ORG Subject: Re: libc_r, signals and modifying sigcontext Message-ID: <Pine.SUN.3.91.1010829165952.9788A-100000@pcnet1.pcnet.com> In-Reply-To: <55heuqipxk.wl@tripper.private>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> At Wed, 29 Aug 2001 14:31:25 -0400 (EDT),
> Daniel Eischen wrote:
> >
> > On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> > > Hi all,
> > >
> > > [SNIP]
> > >
> > > How do you think to add sigreturn function into libc_r?
> >
> > Your implementation of sigreturn is not correct for our threads
> > library. You don't need the strong reference in -current.
> Does it need in -stable?
I'm not sure.
> > The signal mask in the ucontext_t is the _process_ signal
> > mask. This is not the threads signal mask which can be
> > different. It may work in your case because your threads
> > don't change their signal mask, so it may be the same as
> > the process signal mask.
> Right, I made mistakes, my sample is too simplified. Now I understand
> it, thanks.
>
> > I'm not sure what sigreturn should do in a threaded environment,
> > particularly if it should restore the threads signal mask or
> > not.
> At least on Solaris, we can restore sigmask for thread at signal
> handler using setcontext(uc) to return from signal handler, but I'm
> not sure ucontext in Solaris is whether per thread object or per
> process object. On the other hand, we cannot restore the sigmask for
> thread when we return from signal handler with libc_r. So we need
> similar function as Solaris's setcontext, of course setcontext may do
> more than sigreturn do. And the most important fact is we cannot
> implement sigreturn in user programs because it need to know the
> actual implementation of thread library.
sigreturn should be pretty compatible with setcontext. You can
do a setcontext on the ucontext_t argument passed to a signal
handler to restore the state prior to the signal. This is exactly
what sigreturn does. FreeBSD doesn't have {get,set,make}context
yet.
> Java VM needs this function. My previous example explains how JIT
> compiled codes in Java VM works. Actual codes which may cause SIGSEGV
> or SIGFPE does not always raise signals.
>
> > In order to make it work the you want it to, and I'm
> > not sure that is the correct thing yet, you need to change
> > the signal mask in the ucontext before the signal handler
> > is invoked. This would be done somewhere in uthread_sig.c.
> > You would put the threads signal mask (before OR'ing in
> > the sa_mask from the installed handler) into the ucontext.
> > This would make the ucontext passed to a signal handler
> > contain that threads signal mask, not the process signal
> > mask. Then when implementing sigreturn, you restore the
> > threads signal mask from the ucontext, place the process
> > signal mask in the ucontext, and _thread_sys_sigreturn().
> >
> > Here's a quick (uncompiled, untested) attempt at a fix.
>
> Your patch seems to work, yes I tried with test.c modified to specify
> per thread sigmask. But now I have worry about when there are another
> signals pended.
I think that when there are multiple signals pending, the kernel
installs multiple trampolines, so when one signal handler returns
the next signal handler is called. If you sigreturn, setcontext,
or just exit the signal handler normally, the next signal handler
will be called. If you longjmp out of the handler though, you
bypass all the other pending handlers and lose those signals.
I've tested this under -current.
> The actual work needed for sigreturn is restore the
> sigmask to unblock the very signal masked at uthread_sig.c(line 1070)
> temporarily. Using thread->sigmask for sigreturn may do overwork.
> How do you think about this?
If there were multiple trampolines set up by the kernel, then
the threads library will get the next signal when the thread
sigreturns or exits the signal handler normally. There may be
a small race if two or more signals happen really close together
and the threads library installs multiple signal frames for
a thread before getting a chance to execute that thread. In
this case, a sigreturn might bypass the other frames that have
been setup.
If you install the signal handlers with the sa_mask all set,
then this won't happen and all signals will be masked for the
thread while it is in the signal handler.
--
Dan Eischen
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010829165952.9788A-100000>