"Martin Wille" <mw8329@yahoo.com.au> wrote in message news:4022A656.509@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