Hello,
On May 9, 2005, at 3:54 PM, Daniel Eischen wrote:
On Tue, 10 May 2005, Peter Jeremy wrote:
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote:
I have what I think is a serious performance issue with fbsd 5.3
release. I've read about threading issues, and it seems to me that
that is what I'm looking at, but I'm not confident enough to rule out
that it might be a hardware issue, a kernel configuration issue, or
something to do with the python port.
There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My
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 http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall.
-- 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]"
