Performance issue

Suleiman Souhlal ssouhlal at
Mon May 9 21:17:06 PDT 2005


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

zZzZ:~/py% LD_LIBMAP="" ktrace -t c python 10000 > /dev/null && kdump -T | grep sigprocmask
   2991 python   1115698354.240301 CALL  sigprocmask 
   2991 python   1115698354.240304 RET   sigprocmask 0
   2991 python   1115698354.240307 CALL  sigprocmask(0x3,0x2810a830,0)
   2991 python   1115698354.240308 RET   sigprocmask 0

compare with libpthread:
zZzZ:~/py% ktrace -t c python 10000 > /dev/null && kdump - 
T | grep -c sigprocmask

Is this a bug in libc_r?

Suleiman Souhlal     | ssouhlal at
The FreeBSD Project  | ssouhlal at

More information about the freebsd-stable mailing list