RE: [boost] future of boost.threads
Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated. I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html) Just my (possibly unwanted) $.02. Patrick -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Burc Arpat Sent: Thursday, February 05, 2004 5:14 AM To: boost@lists.boost.org Subject: [boost] future of boost.threads i was actually waiting for the rush of the new release to go away to ask this question: i have seen some recent discussions regarding the threads library and from what i gathered there are plans to start working on it again. but, it also seems the original owner of the lib has disappeared from the list here at the petroleum eng. dept. of stanford university, we use boost rather heavily and lately we started into looking parallelization issues. we, of course, would like to use a cross-platform library such as boost.threads but are a bit worried about the future of it so, i guess, the questions are: is there gonna be a new release of boost.threads? if so, are there any plans to change the interface to a degree that it will require significant changes in the user code? with that said, let me also state that, i will be more than glad to give full test support for the library if any changes are being considered burch
On Thu, 5 Feb 2004 09:20:09 -0500, Bennett, Patrick wrote
Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated.
All true.
I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html)
I say that it depends. If you need networking, threading, event loops, etc, in C++ right now then yes, by all means you need to look at ACE. That said, ACE is a huge library that is reasonably difficult to learn and that suffers from it's own legacy. That legacy includes a long list of platforms, compilers, and standard libraries that don't even come close to standard C++. As a result ACE's code base is a macro nightmare and it doesn't utilize the standard library as much as I'd like to see (it was around pre-standard library). Right now boost threads is a minimalist solution without all the legacy. So if I was trying to do some basic thread management I'd be looking at Boost first and ACE second. Further, even though I have used ACE sucessfully for years, I'd like to see Boost libraries for networking and threading continue to move into ground where I currently use ACE. The reason is simply that I believe choice and diversity is good. And if the standards committee is ever going to look at a networking library I'd like to have a Boost, more minimalist solution on the table for discussion because I don't see how ACE can fill that bill.... Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Thu, 5 Feb 2004 09:20:09 -0500, Bennett, Patrick wrote
Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated.
All true.
I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html)
I say that it depends. If you need networking, threading, event loops, etc, in C++ right now then yes, by all means you need to look at ACE. That said, ACE is a huge library that is reasonably difficult to learn and that suffers from it's own legacy. That legacy includes a long list of platforms, compilers, and standard libraries that don't even come close to standard C++. As a result ACE's code base is a macro nightmare and it doesn't utilize the standard library as much as I'd like to see (it was around pre-standard library).
ACE is also a dependency nightmare. If you want any of those components, you have to link the whole enormous ACE library into your application. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 08 Feb 2004 15:12:46 -0500, David Abrahams wrote
ACE is also a dependency nightmare. If you want any of those components, you have to link the whole enormous ACE library into your application.
Yes I agree, which is in contrast to Boost. I think because Boost started as a collection of reasonably independent libraries from independent authors boost libraries are both intentionally and naturally better decoupled than ACE which was initially developed by a single author. BTW, there was a project to split ACE up into more consumable parts, but I don't think it really ever finished. However, it is an interesting study given the depth of experience embodied in the ACE project. There are details here: http://www.cs.wustl.edu/~doc/RandD/ACE/Docs/subsets.html If you look carefully at the table in the URL you will note that the "For TAO" (CORBA Orb implementation) subset is ~80%. What that means is that you can build a full CORBA Orb, which is obviously a pretty intense set of networking code, and ditch 1/5 of the library right off the top. Then you'll note the Utils is another ~18% of the library. In Boost the stuff in Utils like program options parsing, time stuff, etc would clearly be split up into several smaller libraries which may or may not be used by a particular app. So there is alot that can go. Taken another way, the core parts of ACE needed to write serious networked apps are: OS (this is basically boost::config for network and other stuff) Utils (command line parsing, date-time, etc) Logging (no boost equivalent yet) Threads (boost::threads) Demux (no boost equivalent yet) Connection (no boost equivalent yet) Sockets (no boost equivalent yet) If you add it up that's only about 50% of the library. And that's an over estimate because there is some precentage of the Utils that probably isn't needed ever... Jeff
Bennett, Patrick schrieb:
Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated. I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html)
Just my (possibly unwanted) $.02.
Not unwanted, but critizeable. I honestly think, that boost is the right place for a Thread Library, because platform independent interfaces for concurrent programming are one of the most interesting features and many people ask for its inclusion in the C++ standard. We do use the current Boost Thread library already (although some important features are missing) and a successfull crossplatform implementation via boost would proof the committee that it is realizable. I know, that this job is very hard due to the problem area itself as well as due to unresolved questions which interface would do the right thing. I was so glad, when I heard during the last ACCU in Oxford the talk of Kevlin Henney concerning an alternative ansatz for such a thread library and one of my biggest hopes was, that there could be positive interferences between the current boost interface and that of Kevlin. I also asked in this news group for such a possibibility, but got no answer. Finally I want to congratulate William Kempf and all the other boost participants for their work in the current Thread library (and the rest of boost of course) and I hope that it will evolve further on! Just my 0.02 EURO. Daniel
participants (4)
-
Bennett, Patrick -
Daniel Krügler -
David Abrahams -
Jeff Garland