Re: Thread::detach() call doesn't return

[Nacho de los Ríos Tormo]

> On Monday 31 March 2003 01:20 pm, Ian Gough wrote:
> > If you are linking in the older code as a dynamic lib, make sure that it
> > was compiled with the multithreaded libs.

I do link with 'g++ -lpthreads'. Is this enough, or am I missing some option 
in the compiler command line?

> > I don't know if this will help, but I would try fully constructing the
> > thread object before attempting to start/detach it. Is there a
> > difference between how your program works using start() instead of
> > detach()?

Thank you for the suggestion. However, I've found it makes no difference 
whether I use detach() or start() within the constructor or outside.

El Miércoles, 2 de Abril de 2003 05:00, David Sugar escribió:
> "detach" is meant to be used in place of "start" to start a constructed
> thread which has no sync/start/signaling sempahore passed as part of it's
> constructor.  If a thread is started, it is normally in the joinable state.
> Using detach as an alternate to start creates a thread context that is
> detached and cannot be joined.  You cannot delete a detached object safely,
> since it may still have an active execution context.  Detached thread
> objects must self delete, typically by using "delete this" in their Final()
> method. In any case, neither detach nor start may be called from a
> constructor.

Thanks for the clarification -- I've still much to understand about the 
underlying system. But the examples in the documentation show detach() being 
called from the constructors ... Anyway, as I say above, it makes no 
difference in my case.

The objects are never deleted, in my program, and it is meant to be ran 
forever: this will surely demand improvement later on.

There MUST be something in the preexisting code that causes the thread system 
to die or malfunction, just for BEING THERE. Once this code is linked, even 
if it is not called at all, or if if it is called from main(), the first 
thread to be ran or detached starts up and never returns. It runs fine, 
though, and might create further threads if it needs to.