Re: Threads

[Pierre Phaneuf <pp@ludusdesign.com>]

Michael Day wrote:

> That reminds me. An interesting (if flawed) use of threading I have came
> across is using the main thread to fork off a bunch of other threads that
> do all the actual work, while the main thread just blocks for signals.
> What are peoples opinions of this technique? I see some advantages:

Pretty interesting idea actually.

> - it's kinda neat, and it avoids using signal handlers

Yes, that's really neat and cool, I agree!

> - the main thread should not take any cpu time, in theory

In theory. That should be good on pretty much any Unix, but for Win32, I
wouldn't count on signals working correctly (or on *ever* getting one),
much less sigwait().

> There are several disadvantages, and probably some that I've missed:
> 
> - the main thread *does* take up memory
> 
> yep, even with copy on write it'll chew up kernel tables and memory. I
> don't really care about that, as memory is cheap, but I'm sure some people
> will.

Not too bad. Actually, with threads, there is *no* copy-on-write, that's
one of the feature (it doesn't copy at all, you share the same area of
memory). So a few kernel resources, yes, but not much memory, maybe less
than you think!

> - how do you quit the process when all the child threads have finished?
> 
> either the last child thread fires off a signal to the main thread, or
> better yet it just calls exit() itself. Given that I'm using this for a
> server which in theory will not go down, and if it does will do so by
> being sent a QUIT signal, this isn't really an issue :)

This is mere technicality.

> - it's unnecessary and foolish
> 
> yeah, but it's kinda cool, isn't it? isn't it?? No? Oh well. I like it,
> anyway. Beats having a signal handler that says a variable, then have one
> of your threads check for that variable and do something appropriate
> (given that doing anything inside the signal handler itself tends to set
> off asynchronous fireworks).

Yeah, it *is* cool. :-)

> Apologies if I haven't described what I'm actually doing adequately, and
> apologies if I'm ranting about something too trivial :) But I like using
> this method to organise the program and catch signals, and would be
> interested to hear if there are any gaping flaws in it other than those
> which I already know about :)

There *is* a detail you missed and is a freakin' showstopper for this:
on Linux at least, every thread has a separate entry in the process
table and they each receive their own signals in their own thread. In
fact, this point make everybody pull their hair out when it comes down
to signals.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi