[boost] Re: Thread Interest Query

From: Dan'l Miller (optikos_at_[hidden])
Date: 2002-06-12 07:24:29

> I'm posting to ask if there is any interest in a thread library
> that has taken a different approach than boost.threads?

  Yes, there is interest in having an alternative to Boost.threads.

> I have a
> thread library that provides a more OO interface, has different
> methods to deal with things like cancelation and as well as some
> other things. It's very nice for working with task-oriented
> designs. I'm not suggesting it as a replacement for boost.threads
> or anything like that.

  I differ with you there.  There is interest in having a competitor to Boost.threads for survival-of-the-fittest reasons.

> The design of the two libraries is pretty
> different and I wonder if maybe including options for either would
> be better than trying to address everything in one library.

  I differ with you there.  I see no reason that there needs to be two ways of representing a thread in C++0x.  I see no reason that there needs to be two ways of representing a mutex in C++0x.  There should be one multithreading library of larger scope than Boost.threads.  For example, Boost.threads considers interaddress-space synchronization (e.g., inter-process semaphores controlling shared memory) as out of bounds.

> It seems as
> though there are situations where either one might be a little more
> suitable than the other for different applications (you want to use
> scoped locking all the time, or you want the option of doing it
> explicitly, you want to use a cancelation mechanism or you want to use an
> interruption mechanism, and so on)
[...snip...]

  I am certain that such an alternative competing library would be helpful in establishing which library better matches the expectations of existing industrial practice regarding multithreaded software.

  The question is:  Is Boost (both at a mission/governing-rule-set/axiomatic level as well as at a society-of-people/psychological level) willing to permit multiple libraries on substantially the same topic which unavoidably compete with each other within Boost & outside of Boost for mindshare?

  As developer Whosie Whatsit develops some new library Boost.foo which has as its mission being thread-safe, Whosie would choose between Boost.threads versus your new Boost.Zthreads or whatever its name would be.  Presumably this decision could be made at a resource-by-resource basis, but likely would be entirely Boost.threads or entirely Boost.Zthreads throughout the Boost.foo library's design.

  By permitting two competing libraries on substantially the same topic, Boost would be implicitly saying "Be fruitful & multiply; go forth & prosper." to both libraries.  If one dies off due to unpopularity or lack of critical acclaim, then it is obvious which library industrial practice effectively chose to submit to C++0x for standardization.  If both are popular, then it is less clear which one to submit for C++0x standardization and less clear what J16/WG21 should do (i.e., standardize them both? pick one or the other as is?  meld them together?).

> - Eric
> http://www.cse.buffalo.edu/~crahen
>