deischen at freebsd.org
Mon May 9 22:24:10 PDT 2005
On Tue, 10 May 2005, Suleiman Souhlal wrote:
> On May 9, 2005, at 7:21 PM, Daniel Eischen wrote:
> > I don't think that patch is correct. You need the signal mask
> > in the kernel to match in case of an exec() after a fork()
> > for instance. If the application fork()'s, then changes the
> > signal mask in the child (which is now single threaded), then
> > the child exec()s, the mask is wrong.
> > If the process wasn't linked to libpthread, then the longjmp()
or any thread library.
> > and setjmp() would still be calling the syscall, so it isn't
> > the syscall itself that is making things slower. You'll notice
> > that there are two calls to __sys_sigprocmask() in the section
> > of code you have patched. You could eliminate the second call
> > if you do some of what the remainder of the function does instead
> > of returning early (the locks aren't needed and pending signals
> > don't need to be run down).
> Processes linked with libc_r NEVER call the syscall, once they have
> started (after rtld-elf):
> Is this a bug in libc_r?
No, libc_r wraps execve() and a lot of other syscalls that libpthread
or libthr don't need to. Take a look at libc_r/uthread/uthread_execve.c
and you will see it sets the signal mask before exec()ing.
More information about the freebsd-stable