On 30-Mar-2000 Christopher Smith wrote:
> -----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.
Perhaps, but its not much different from any other technique using
threads to process events.
> It would also potentially conflict with someone at the user-level
> deciding to block the signal.
No, because the kernel's idea of the signal block mask needn't be the
same as the user-level model. Lots of this can be done in user-mode.
> 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.
Are you sure SIGEV_THREAD is about performance? It doesn't sound like it
is, because any mechanism which requires thread creation at signal
delivery time is going to be very slow compared to simply delivering it.
It sounds to me that it has a lot more to do with turning signals
from async to synchronous events, which is a much saner way of dealing
with signals than the traditional way. Does it really spec thread
creation, or simply that another thread (other than any of the
application's threads) handles the signal?
> 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).
Do you? What's "at once"? What if starting a new thread takes 10 times
longer than running the signal handler, which is a pretty realistic
scenario. A thread pool is about the only sane way of dealing with what
you're talking about; if concurrency of signal delivery is really a
concern, you just bump up the number of handler threads (but to no more
than the number of CPUs, because after that there's no concurrency).
J
-
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:27 EST