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

From: williamkempf_at_[hidden]
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 
I've missed.

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 
the case?
 
> >... Please, though, keep in
> > mind that we are NOT writing a POSIX C++ wrapper here but 
defining a
> > 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.

Bill Kempf