-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Mar 30, 2000 at 09:22:20AM -0800, Jeremy Fitzhardinge wrote:
> On 30-Mar-2000 Christopher Smith wrote:
> > On Wed, Mar 29, 2000 at 05:47:13PM -0800, Jeremy Fitzhardinge wrote:
> > 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.
While the performance may seem poor, the performance for the thread
which would otherwise be receiving the signal is very good, and of
course, if you know you have to spawn off a thread anyway, the
performance is excellent.
> 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?
Doing synchronous handling of events can already be done with
sigwait() as you've described. This is something more. It's allowing
you a fairly asynchronous set of behaviors without the limitations of
traditional asynchronous signal handling (like the current thread of
execution is interrupted, and you can't use POSIX thread
synchronization primitives). The spec does not specify thread creation,
and indeed it could be done using some kind of a thread pool. However,
I'd expect any attempt to build a thread pool for this might as well
be merged with any larger thread-pooling efforts one might have going
on.
> > 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).
Actually, not true. Thanks to the fact that you have access to all the
API's any other thread would have, each handler could indeed block
forever on a mutex or condition variable. Indeed, if you were insane
enough you could use signals to tell an application to spawn more
threads. ;-) So, you could potentially need an infinite number of
threads to maximize concurrency. While you could use a thread pool to
improve the performance here, it'd make more sense to be doing this
for all threads which might be invoked by pthread_create() rather than
just threads created by SIGEV_THREAD, as the only thing that is
special about SIGEV_THREAD is what causes the thread to be created in
the first place.
Even a thread pool is going to require use of mutexes and condition
variables to work right, so you're going to be dipping in to the
kernel one way or another. It just seems like this is one case where
the kernel can avoid a lot of jumping around because you KNOW a thread
is going to have to made available immediately.
- --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/>
iD8DBQE44+SafrrCpthD+UYRApQtAKDWa265m7HAXcfPx5N5bJY9amauQACfXRwW
CYx81YCdlcHeFlo2/9brKxI=
=DI5c
-----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:28 EST