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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-31 16:23:56

> > do you really want pthread_detach after each
> > pthread_self() !? this is hardly what is needed
> > here unless i am missing something big.
>
> Actually, this is a bug, but not probably for the reasons you
> thought.  Detaching every time is fine for the Boost.Threads
> implementation, since we use a CV for join() instead of pthread_join
> ().

well, in posix terminology you can detach (or join)
the same thread only once:

"The effect of multiple pthread_detach( ) calls on
 the same target thread is unspecified."

"When a pthread_join () returns successfully, the target
 thread has been terminated. The results of multiple
 simultaneous calls to pthread_join ( ) specifying the
 same target thread are undefined."

and i have yet to see/understand semantics of non-posix
detach and join which would allow to do it multiple
times. i would suggest that you choose different names
if you really want to (and i doubt you can) go in non-posix
direction..

> The problem is, if the thread in question was not created by
> Boost.Threads but by POSIX calls directly then this may yank the rug
> out from underneath someone.  I'll have to fix this.
>
> > also,
> > your DuplicateHandle/CloseHandle is really an
> > overkill.. keeping just ONE handle and TLS/TSD
> > key association is much more attractive/
> > efficient, IMHO.
>
> Actually, the DuplicateHandle is required.  It's the only way to
> promote the pseudo-handle returned from GetCurrentThread() into a
> real handle.  The reason for using GetCurrentThread() instead of TSD
> is twofold.  First, the TSD approach will chew up a TSD slot, and if
> we can avoid doing so we should, since TSD slots are limited to 64 to
> begin with.

that is not a problem if you are willing to implement ThreadLocal class
(see Java) which would keep the locals inside some thread's container;
member of thread class instance <- thread object.

> The more important reason, though, is that the TSD
> approach will only work with threads created by Boost.Threads.  The
> GetCurrentThread() approach safely adopts all threads into the
> library.

the real problem is the reclamation of dynamically created thread
object (and destruction of its thread locals) attached to that
"foreign" thread on win32 which does not have TSD destruction
mechanism; but this is solvable.. well, sort of.. see pthreads-win32.

> > why not "static thread& thread::current()" ?
>
> Because this would be difficult to implement.  I could manage this
> with TSD but that's a lot of overhead (actual heap allocations would
> be needed and clean up stacks used) for little benefit in the
> interface.

heap allocation is needed for detachable threads only;
not for joinable.

> Actually, on reflection, even TSD won't work here.

i do not see any reasons why it won't work here (thread::current).

> The thread object needs to exist beyond the lifetime
> of the thread context.

not necessarily; for joinable threads only. btw, that is why
you cannot detach non-dynamically allocated thread object(s)
and why you can detach dynamically allocated thread object(s)
only; but not static/auto storage duration thread objects.

> There is no way to safely implement this with a reference return.

i do not follow you here.. thread::current() can only be called
on the current thread context.

regards,
alexander.