[boost] Re: Re: future of boost.threads

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-02-06 06:30:52

"Martin Wille" <mw8329_at_[hidden]> wrote in message
news:4022A656.509_at_yahoo.com.au...
> Michael Glassford wrote:
>
> >>if so, are there any plans to change the interface to a degree
> >>that it will require significant changes in the user code?
> >
> >
> > Definitely not.

Let me clarify. There were several thoughts in my mind, and since I
was busy and answered quickly my response didn't express them all
clearly.

First, there are no present plans to make any changes to the existing
library, with these exceptions: bug fixes (which aren't likely to
require significant changes to user code); the changes already made by
William Kempf in the thread_dev branch of CVS, at least those that are
finished (it is possible that some of these may require changes to
user code); and additions that are implemented on top of the present
library, for example some form of the read-write locking and barrier
implementations that are currently in the thread_dev branch (none of
these would require changes to user code unless you're using
"pre-release" implementations from the thread_dev branch).

Second, the intention is that these changes, as well as any future
plans, will make as few modifications to the existing library as
possible and will do so in a way that is as backward-compatible as
possible without hindering good design; also, that no significant
changes of any kind will be made without being discussed here first.

Third, I thought that there might be a fear in some people's minds
that new people working on the thread library might result in a
radical change of direction for the library, changes being made
rapidly or carelessly without a clear understanding of why things were
implemented the way the are now, etc. I don't think that will be the
case and hope that I've eliminated those fears.

In short, William Kempf did a good job of carefully creating a useful
set of threading primitives. The intention is to change his work only
if necessary and very carefully. I'm pretty sure his original plan was
to get these primitives solidly in place, then to explore ways to use
them to implement more advanced threading idioms (for example, Kevlin
Henney's, mentioned by Daniel this morning and by several others in
the past). In my mind this is the correct path to pursue.

> It depends on which assumptions you make about the implementation
> of Boost.Thread. Some parts are underspecified and if you make
> the wrong assumptions then you'll have to fix your code, once
> the specification is revised (eg., some time ago,  I submitted a
> list of changes I suggest to the specification of the tsp).

This is a valid point that I hadn't considered in my original
response; thanks for bringing it up.

I haven't forgotten your list of changes.

> Regards,
> m
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>