«

Other than looking cleaner in the object oriented approach (each
thread's main function in one class) vs. having UINT _ _stdcall
ChildThread (void *args) {...} required declarations for Windows
kernel calls, I'm not sure about the advantages of the first method
compared to the second method. I'm not sure if I have given enough
information on what I'm confused on, but any enlightenment would be
much appreciated. Thanks.

ssylee wrote:
> Other than looking cleaner in the object oriented approach (each
> thread's main function in one class) vs. having UINT _ _stdcall
> ChildThread (void *args) {...} required declarations for Windows
> kernel calls, I'm not sure about the advantages of the first method
> compared to the second method. I'm not sure if I have given enough
> information on what I'm confused on, but any enlightenment would be
> much appreciated. Thanks.

Are you talking about detached threads vs a thread class ?

If you are, my experience is that if you want a process to exit cleanly,
it must close all it's threads before calling exit or returning from
main. Then the question becomes, how do you reliably manage that. I
have found that the "thread class" model where calling the destructor on
a class as an implicit join is sufficient and succinct. There are other
solutions as well but I think since threaded SW is harder to write,
keeping the options simpler is better.

That said, there are plenty of examples in the austria c++ unit tests of
using threads as a class.

http://austria.svn.sourceforge.net/v...=1&view=markup

On Jan 28, 2:49 am, Gianni Mariani <gi4nos...@mariani.ws> wrote:
> ssylee wrote:
> > Other than looking cleaner in the object oriented approach (each
> > thread's main function in one class) vs. having UINT _ _stdcall
> > ChildThread (void *args) {...} required declarations for Windows
> > kernel calls, I'm not sure about the advantages of the first method
> > compared to the second method. I'm not sure if I have given enough
> > information on what I'm confused on, but any enlightenment would be
> > much appreciated. Thanks.

> Are you talking about detached threads vs a thread class ?

> If you are, my experience is that if you want a process to
> exit cleanly, it must close all it's threads before calling
> exit or returning from main.

At the very least, you must ensure that all threads are in a
quiescent state, and will stay that way during shutdown. Having
them all terminate, and joining them to ensure that they have,
is certainly the surest solution, although there are others that
can be made to work in practice.

> Then the question becomes, how do you reliably manage that. I
> have found that the "thread class" model where calling the
> destructor on a class as an implicit join is sufficient and
> succinct. There are other solutions as well but I think since
> threaded SW is harder to write, keeping the options simpler is
> better.

In other words, you "detach" a thread by passing it off to a
reaper thread which does the join, or something like that. That
can be tricker than it sounds as well: if one of the detached
threads runs for an exceedingly long time, and the reaper thread
is joining on it, then the other "detached" threads won't be
joined, and since they're not detached as far as the operating
system goes, they will continue to use resources. In practice,
I don't think that this is a problem very often, and in any
specific program, it is easy to work around, but it does create
a problem for a library solution.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34