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() 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="libpthread.so.1=libc_r.so.5" ktrace -t c python heapsort.py 10000 > /dev/null && kdump -T | grep sigprocmask
2991 python 1115698354.240301 CALL sigprocmask (0x1,0x2810a820,0xbfbfea60)
2991 python 1115698354.240304 RET sigprocmask 0
2991 python 1115698354.240307 CALL sigprocmask(0x3,0x2810a830,0)
2991 python 1115698354.240308 RET sigprocmask 0
zZzZ:~/py%
compare with libpthread:
zZzZ:~/py% ktrace -t c python heapsort.py 10000 > /dev/null && kdump - T | grep -c sigprocmask
92114
zZzZ:~/py%
Is this a bug in libc_r?
-- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED]
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
