From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 11:46:10
--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> Looks great...
> One thought about the following:
> "You can't call some thread methods for foreign threads of
> since the necessary state information may not exist. In particular,
> can not call join() or detach() on foreign threads."
> How about instead of just documenting this restriction, we make it
> impossible for the user to call join() and detach() on a foreign
> not providing those functions in the first pace; i.e., use a
> thread class that doesn't have join() and detach().
> Put another way, is there a strong reason to have only a single
Not an entirely bad idea. Instead of an adopt() method you'd have a
constructor that would take the foreign_thread object (yeah, that
name needs to change). The only problem I see is that when you use
the default constructor (pthread_self() equivalent) the current
thread may not be a "native" thread (yeah, name change). How would
you suggest we work around this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk