Re: [boost] [threading] rewrite (was: Bug list status)
----Original Message---- From: Roland Schwarz
There is a new team that will try to handle the threading library. We are currently busy trying to do a rewrite of the library on a separate branch.
Interesting. Why do you feel it needs a rewrite? (I'm not for a moment suggesting it doesn't, I'm just curious - I know very little about boost::thread). -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894
Interesting. Why do you feel it needs a rewrite? (I'm not for a moment suggesting it doesn't, I'm just curious - I know very little about boost::thread). This has been decided almost a year ago, and is because William Kempf is not available any more. For unknown reasons he was not able to put his work under the new boost license (he did not respond to any attempts to contact him). M. Glassford who took over maintenance currently is tied up with other
Martin Bonner wrote: projects, so we are trying to bridge this gap. The intent is not to change interface while creating a better platform separation of the library. And of course put it under the new license which obviously implies the need for a rewrite. Roland
hello!
...we are trying to bridge this gap...
is it going to take time? is there any plan about when the new release of boost.threads will be availiable? is there plans to add atomic_op(availiale to users) in boost.threads? at the moment I wanna combine them with scoped locking and i will use boost::detail::atomic_count I think boost.threads interface should have such stuff.. thanks in advance
george <ypox13p@yahoo.com> writes:
...we are trying to bridge this gap...
is it going to take time?
Yes.
is there any plan about when the new release of boost.threads will be availiable?
I hope it will be available by boost 1.35.
is there plans to add atomic_op(availiale to users) in boost.threads?
Not in the short term. Once the rewrite of existing functionality is complete, then we'll consider new stuff.
at the moment I wanna combine them with scoped locking and i will use boost::detail::atomic_count I think boost.threads interface should have such stuff..
I agree, it should. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Will P. Dimov and A. Terekhov participate on the rewrite? They provided much input regarding threads in the past. Greetings Franz ----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Monday, March 27, 2006 12:18 PM Subject: Re: [boost] [threading] rewrite
george <ypox13p@yahoo.com> writes:
...we are trying to bridge this gap...
is it going to take time?
Yes.
is there any plan about when the new release of boost.threads will be availiable?
I hope it will be available by boost 1.35.
is there plans to add atomic_op(availiale to users) in boost.threads?
Not in the short term. Once the rewrite of existing functionality is complete, then we'll consider new stuff.
at the moment I wanna combine them with scoped locking and i will use boost::detail::atomic_count I think boost.threads interface should have such stuff..
I agree, it should.
Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dr. Franz Fehringer wrote:
Will P. Dimov and A. Terekhov participate on the rewrite? They provided much input regarding threads in the past.
I would welcome them very much, but I did not yet hear from them. We certainly could still could need helping hands Roland
Perhaps you could write to them directly? At least A. Terekhov seems to be not currently present on the list. Greetings Franz ----- Original Message ----- From: "Roland Schwarz" <roland.schwarz@chello.at> To: <boost@lists.boost.org> Sent: Saturday, April 01, 2006 12:49 PM Subject: Re: [boost] [threading] rewrite
Dr. Franz Fehringer wrote:
Will P. Dimov and A. Terekhov participate on the rewrite? They provided much input regarding threads in the past.
I would welcome them very much, but I did not yet hear from them. We certainly could still could need helping hands
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peter Dimov wrote:
Or write them at all, for that matter. Is this development documented, tracked or announced somewhere?
This attempt has been started a year ago, but almost nothing happened since then. Recently David Abrahams polled the list for what is going on with the thread_rewrite. Anthony Williams and I committed ourselves to move things forward now. A dedicated mailing list has been set up, which also is hosted at boost. I invite you to subscribe to this list to find out what is going on, The list also is available on gmane. Anthony is focusing on the windows rewrite. I am primarily trying to get the windows tss rewrittten. But before doing this I will manage to set up a better platform separation framework. I think most of the starvation has been due to the single source file approach for the multiple platforms. Other than typical libraries threading has a much stronger dependence on target platform. I hope that this approach will make it much easier to find independent platform maintainers. I already have written a platform dispatch header and currently trying to get something similar for bjam. I will present this when available, and also try to document this on the wiki. Please be patient until this is done. I am open for critics afterwards and would be very glad if there is plenty of them. But I want to avoid that there is excessive discussion taking place while no real work is getting done, as has been for the past few years. I am in no means attempting to take over the boost_thread library but instead just trying to coordinate further development because I think it would be too bad if all this excellent work wouldn't survive. In the meantime please try to focus on the current issues: We urgently need help with fixing the open bugs/ applying patches for 1_34. I have volunteered to act as a "proxy-maintainer" for this too. So if you have time to help I would be very pleased if you contact me. Currently I am searching for someone having access to a 64 bit compiler on the windows platform. Roland
Roland Schwarz <roland.schwarz@chello.at> writes:
I am in no means attempting to take over the boost_thread library but instead just trying to coordinate further development because I think it would be too bad if all this excellent work wouldn't survive.
I just want to add that it wouldn't be a bad thing if you /were/ trying to take over the library. Someone (or many someones) should. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I just want to add that it wouldn't be a bad thing if you /were/ trying to take over the library. Someone (or many someones) should.
I certainly would be glad to volunteer for this task. I just wanted to point out that if someone else thinks he/she is better prepared for this business I will not get into his way. So if there is common sense about this you can treat me as the new maintainer. At the same time I want to point out that I definitely will need a lot of help from others. Watching the thread development for a while now makes me almost sure that this job is too much for a single person to do. Lot of expertise about the different platforms is needed. Roland
Roland Schwarz wrote:
So if there is common sense about this you can treat me as the new maintainer. At the same time I want to point out that I definitely will need a lot of help from others. Watching the thread development for a while now makes me almost sure that this job is too much for a single person to do. Lot of expertise about the different platforms is needed.
I think this is why nobody volunteered to take that job for such a long time. Perhaps, it would make sense to have platform maintainers for Boost.Thread in addition to a library maintainer. Similar groups might need to be formed for other libraries in the future (e.g. filesystem, asio or anything GUI related have many platform specific aspects, too). Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille <mw8329@yahoo.com.au> writes:
Roland Schwarz wrote:
So if there is common sense about this you can treat me as the new maintainer. At the same time I want to point out that I definitely will need a lot of help from others. Watching the thread development for a while now makes me almost sure that this job is too much for a single person to do. Lot of expertise about the different platforms is needed.
I think this is why nobody volunteered to take that job for such a long time. Perhaps, it would make sense to have platform maintainers for Boost.Thread in addition to a library maintainer.
I'm happy to be listed as platform maintainer for Windows. If no-one else takes on POSIX, I could do that too, (though I thought we did have a volunteer), but I know nothing about MacOS, and don't have access to a Mac. It's good to have someone take overall responsibility. Thanks, Roland. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Anthony Williams wrote:
I'm happy to be listed as platform maintainer for Windows.
Fine! Since you are already signed up for this there is no need to change much. Thanks, Anthony. I also hope that I can count on you helping fixing bugs for the the upcoming 1-34 release.
If no-one else takes on POSIX, I could do that too, (though I thought we did have a volunteer), but I know nothing about MacOS, and don't have access to a Mac.
Since I am about to switch over to linux based systems, I would be interested to take over this part, while waiting for Matt Hurd who AFAIR intended to focus on this. Since pthreads is available on a lot of platforms (win32 too) I intend to extend the support for pthreads implementation, i.e the library user should be able to choose between pthreads versus native implementation where available. Also this approach will make it possible to get boost_threads ported to a new platform fast, while still give the option to do a native implementation later. Having pthreads implementation available on most platforms also will give a reference implementation to check for correctness and the like. I contacted Mac Murret (the contributor of the mac implementation) offlist. He told me that it is not meaningful to support MP on mac anymore since while still available it is an emulation layer on top of pthreads which in turn is on top of the native interface. Supporting pthreads he thinks is sufficient while possibly optimize for Mac Threads might be meaningful in some specific areas. He will be available if we need someone to do a test compile once we have pthreads in place.
It's good to have someone take overall responsibility. Thanks, Roland.
Hopefully I will be able to meet your expectations. Roland
Roland Schwarz <roland.schwarz@chello.at> writes:
Anthony Williams wrote: I also hope that I can count on you helping fixing bugs for the the upcoming 1-34 release.
Of course. Let me know which ones to look at.
If no-one else takes on POSIX, I could do that too, (though I thought we did have a volunteer), but I know nothing about MacOS, and don't have access to a Mac.
Since I am about to switch over to linux based systems, I would be interested to take over this part, while waiting for Matt Hurd who AFAIR intended to focus on this.
Fine, it's all yours.
Since pthreads is available on a lot of platforms (win32 too) I intend to extend the support for pthreads implementation, i.e the library user should be able to choose between pthreads versus native implementation where available. Also this approach will make it possible to get boost_threads ported to a new platform fast, while still give the option to do a native implementation later. Having pthreads implementation available on most platforms also will give a reference implementation to check for correctness and the like.
Agreed.
I contacted Mac Murret (the contributor of the mac implementation) offlist. He told me that it is not meaningful to support MP on mac anymore since while still available it is an emulation layer on top of pthreads which in turn is on top of the native interface. Supporting pthreads he thinks is sufficient while possibly optimize for Mac Threads might be meaningful in some specific areas.
That's good to know; it does simplify implementation. Are the older MacOS releases not worth supporting any more, then?
He will be available if we need someone to do a test compile once we have pthreads in place.
And it's good to have someone who can test things. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Since we are changing topic: I've moved this thread to the thread devel list. Roland
participants (8)
-
Anthony Williams -
David Abrahams -
Dr. Franz Fehringer -
george -
Martin Bonner -
Martin Wille -
Peter Dimov -
Roland Schwarz