Performance issue

Daniel Eischen deischen at
Mon May 9 16:21:29 PDT 2005

On Mon, 9 May 2005, Suleiman Souhlal wrote:
> On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
> > The threading libraries don't play with the signal mask.  In fact,
> > libpthread has userland versions of sigprocmask() et. al. and won't
> > even make the syscall() unless the threads are system scope.  There
> > is a special thread in libpthread that handles signals which does
> > use the system sigprocmask(), but unless the application is
> > making heavy use of signals in general, it shouldn't matter.
> I think I've found the problem: Python uses setjmp/longjmp to protect
> against SIGFPU every time it does floating point operations. The
> python script does not actually use threads, and libpthread assumes
> non-threaded processes are system scope. So, it would end up using
> the sigprocmask syscall, even though it doesn't really need to.
> The diff at
> thr_sigmask-20050509.diff fixes this, by making sure the process is
> threaded, before using the syscall.

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()
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).


More information about the freebsd-stable mailing list