Date: Mon, 9 May 2005 19:21:27 -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.0505091907060.27904-100000@sea.ntplx.net> In-Reply-To: <4D923762-6562-440B-8456-EA404F7FDA44@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 http://people.freebsd.org/~ssouhlal/testing/ > 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). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0505091907060.27904-100000>