Re: boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-05 16:49:27

Scott McCaskill wrote:
> I have an application that
> > > creates several threads and I want the main thread to be able to find
> out if
> > > any of the created threads have died.
> >
> > This sounds like a possible design error.
> > Why does the main thread want to know?
> >
> 
> So that it can create a new thread to replace the old one.

        Hmmm. I see. I think that's legitimate.
[I've done it myself .. although in my case there was only
one thread, and it had to restart _itself_ if it died ..
which is done by using a reset controller with a watchdog
timer]

> However, your point is well taken--threads should not exit unexpectedly, 

        While that is true, it isn't a reason not to try to make
the program robust in the face of programming errors or, say,
a hardware fault.

        I think, however, you can implement this the same way I did:
using a watchdog technique. The problem is that you have to put
watchdog reset commands into the worker threads everywhere that
they spend any significant amount of time.

        An advantage is that a new thread is started when
a thread locks up, not just when it is dead: it will be necessary
to tell the system operator about this so that the old thread can
be cancelled from the console. (or, do what a friend did: write
a reaper daemon that harvests zombies).

> and I will
> re-examine this aspect of the design in the future.  However, my immediate
> task is to get the application ported to another platform, so until that is
> done I'm trying to minimize the number of design changes I make.

        But you are talking about rewriting the code using
boost threads -- presumably to make the porting easier.

        Also: your query is correct semantically: you're only
interested in the deterministic case where the a query
would reply that the thread is definitely dead.
So this doesn't look like a design error, after seeing your 
explanation.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net