Date: Tue, 10 May 2005 01:24:08 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Suleiman Souhlal <ssouhlal@freebsd.org> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Performance issue Message-ID: <Pine.GSO.4.43.0505100117320.1139-100000@sea.ntplx.net> In-Reply-To: <361776BC-F969-4F88-8656-E75A5D967186@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0505100117320.1139-100000>