Performance issue

[Daniel Eischen]

On Tue, 10 May 2005, Suleiman Souhlal wrote:

> Hello,
>
> 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.

-- 
DE