Re: boost.thread - class derivated from thread
On Feb 18, 5:12 pm, Lars Uffmann <a...@nurfuerspam.de> wrote:
Yannick Tremblay wrote:
I am not sure why you'd want the parent thread to restart another
thread. I fail to grasp your design.
See threads as multiple workers in a company. All of them have an
inbox for work-to-do. If there's no work to do, the worker sit idle
waiting for stuff in its inbox. (this translate to a
boost::condition::wait ).
I wanted the worker to sit idle, yes. Well, actually I wanted to send
him home to enjoy his freetime, and call him back to work when I need
him again. Thus the restart() :)
I didn't (and still don't) see a point in keeping a thread active in the
background (but doing nothing) if the only purpose of this thread is to
listen for certain network traffic, and the user explicitely switched
off that listen interface. In that case I wanted the thread to stop, and
not take up even 1 cpu cycle until the user wants it resumed.
I'm not sure what state you want to see the thread in. On most
systems today, once a thread has exit'ed, there's no way of
restarting it. And of course, a thread in a wait on a condition
takes 0 CPU time until someone wakes it up.
Is boost::condition::wait really a better approach? Let's say
some bug affects the condition unwanted, that would "trigger"
my thread execution again when I don't want it to. It's like
leaving the car but with the engine idling. If you're unlucky,
something unexpected makes the forward gear jump in, resulting
in some really bad things happening...
I'm afraid I don't see the difference. If someone starts a
thread when it's not wanted, you have a problem.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34