Date: 2001-08-01 15:03:36
--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > Fistly, Boost.Threads are not POSIX threads. As you've seen, they
> > are detached in the POSIX implementation, and must be so.
> if you really do it that way then your threads well become detached
> (in posix terminology). that would mean that you could never call
> pthread_join or pthread_detach (after initial detach); that would
> mean that your "join" would not match posix join with respect
> to thread termination guaranties.
Which is likely a non-issue, and frankly what we want.
> "If the thread is created detached, then use of the ID of the newly
> created thread by the pthread_detach() or pthread_join ( ) function
> is an error."
Since users have no access to the ID directly they can't call
pthread_detach() or pthread_join(), so this one's a non-issue.
> "A conforming implementation is free to reuse a thread ID after the
> thread terminates if it was created with the detachstate attribute
> set to PTHREAD_CREATE_DETACHED or if pthread_detach() or
> pthread_join () has been called for that thread. If a thread is
> detached, its thread ID is invalid for use as an argument in a call
> to pthread_detach() or pthread_join()."
Same as above.
> "For instance, after pthread_join ( ) returns, any
> application-provided stack storage could be reclaimed."
I think this one is a non-issue as well, unless there's something
The only real issue (which I can work around if it's the case) would
be if the ID couldn't be used in calls to pthread_equal(). Is this
> >... Please, though, keep in
> > mind that we are NOT writing a POSIX C++ wrapper here but
> > C++ threading library from the ground up taking into consideration
> > *ALL* existing C implementations.
> ok. however, you have really strange perception with respect
> to POSIX threads standard, IMHO. AFAIK the task of the threads
> working group of IEEE/OpenGroup (long before i've ever heard
> of POSIX and was programming windows, like you) was to define
> a C threading library from the ground up taking into
> consideration ALL existing C implementations (including windows
> API, which was already widely used at that point). the existence
> of pthreads-win32 proves that it could be implemented under windows
> as well. what you are currently doing is creating something new
> (mix of posix and windows) which is unique and unproven, so far.
Yes, and with valid reason. C++ is not C. Some things that make
sense in a C API are either difficult to live with in C++, or even
result in conflicts with the language design. I'm keeping this in
mind even with regards to Win32 threads, which I'm vastly more
familiar with. If there are *specific* issues that POSIX has
discovered that still apply to a new C++ library we'd better pay
attention to them, but there are simply going to be things that
differ between what we define and what POSIX defined.
> that is fine but that is hardly the best approach for something
> which is supposed to become an open standard. because programmers
> from both camps will feel uncomfortable with such a mix without
> having some compelling reasons/justifications.
Firstly, it's not a mix of two APIs. Everything here is designed
from the ground up. Usage patterns and known problems/strengths for
all (not both, other libraries than POSIX and Win32 have been
considered, including from other languages) have been paid attention
to, but none of them are the basis for Boost.Threads.
> i would suggest
> that your carefully analyze the difference in threading concepts,
> make your choice and explain why you have made this or that
> decision? that is what you have already done with condition
> variables, etc.. after having some experience with both windows
> and posix threads programming, i've already made my choice and
> have yet to see some _real_ arguments from you why i (and others)
> should change our minds.
It's in the documentation, and I've iterated the reasons on the
list. If you aren't persuaded there's nothing more I can do. If you
simply don't understand the decisions then I think you need to ask
the right questions. I don't know how to explain things any better
for you. Sorry. I really wish I could, because your expertise in
the whole MT area is definately extensive and I value your opinions
and help in all of this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk