Messages in this thread | | | Date | Wed, 29 Mar 2000 21:37:40 -0800 | From | Christopher Smith <> | Subject | Re: Slow pthread_create() under high load |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Mar 29, 2000 at 05:47:13PM -0800, Jeremy Fitzhardinge wrote: > On 30-Mar-00 Christopher Smith wrote: > > While it's undoubtedly doable in user-space, the whole idea of that > > feature is to avoid signal-handling overhead (and replace it with > > thread creation overhead I guess ;-). I'm not sure how one would do > > THAT in user space without some kind of kernel support. > > You'd simply block that signal in all threads and have the signal handler > thread use sigwait() to wait for the signal to turn up. If your signal > load is heavy enough that you need multiple threads to deal with it, you > can create multiple signal handler threads.
While that could work, you'd need a pretty sophisticated mechanism for determining the number of signal handler threads to use for the job. It would also potentially conflict with someone at the user-level deciding to block the signal. Finally, it would definitely be less efficient, as you'd be first returning from sigwait() and then invoke pthread_create(). The SIGEV_THREAD option allows the kernel to trap the signal, create the thread, and then start executing the function in question before transitioning out of kernel space. In theory at least this can be quite fast. I'll see if I can find actual examples with metrics.
Yes, this is pushing behavior into the kernel on one hand, but if you're a thread fan, you could argue this is actually just the right way to do signal handling in the first place.
One could minimize this overhead by using the "signal handler thread" to execute the handler itself, but this would not give you the same behavior (if I get 3 signals all at once, I expect to have 3 threads running in parallel handling each of them).
- --Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE44ugZfrrCpthD+UYRAjavAJ96MlR9puyZsgJrzw9d1Fn2nFOA1wCfS7ji 4l1pJEuMwvs82VAKFeoB4fY= =AuGz -----END PGP SIGNATURE-----
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |