Re: Threads

[Michael Day <mikeday@corplink.com.au>]

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:

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

'cos you block all signals to your thread, then fire off your children
(who inherit your block on all signals, as is recommended by pthreads
documentation, or whatever). Then you block in sigwait() specifying which
signals you're interested in (INT, TERM, QUIT, whatever) until one of them
arrives, which you can process without jumping through asynchronous 
signal() hoops. I find that kinda cool.

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

it's just blocked in sigwait() unless a signal arrives, so I feel that
should be just as efficient as normal signal() handling. However it's
implementation dependent, god knows what weird things some kernels will do
to blocked pthreads. Still, in theory the technique should not place any
extra burden on the cpu.

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.

- 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 :)

- 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).


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 :)

Michael