-----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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:26 EST