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 - - - G. Burc ARPAT Ph.D. Candidate Dept. of Petroleum Engineering Stanford University Stanford, CA 94305 Internet: www.burcarpat.com
"Burc Arpat" <burch@stanford.edu> wrote in message news:loom.20040205T111202-673@post.gmane.org...
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.
That would be Roland and myself.
but, it also seems the original owner of the lib has disappeared from the list
Yes. Again, if anyone knows how to contact him, please do!
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?
I'm hoping so. At the very least I hope to fix any known or newly discovered bugs. Also, there are changes that William Kempf checked into the thread_dev branch in CVS before he disappeared from the list. I hope to incorporate these changes--or at least the ones that are already finished.
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. Thread cancellation or one of the other features William Kempf was working on may require some changes (I need to look into this), but I wouldn't expect any of them to require major changes. I've communicated with Roland privately, and the changes we are both most interested in (other than those listed above) are changes that build on the existing implementation rather than change it (e.g. new classes that use the existing ones). Most of the changes others have suggested to the Boost.Thread library from time to time also fall into this category.
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
Thanks!
burch
- - -
G. Burc ARPAT Ph.D. Candidate
Dept. of Petroleum Engineering Stanford University Stanford, CA 94305
Internet: www.burcarpat.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas? On Thu, 5 Feb 2004 09:59:03 -0500, "Michael Glassford" <glassfordm@hotmail.com> said:
"Burc Arpat" <burch@stanford.edu> wrote in message news:loom.20040205T111202-673@post.gmane.org...
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.
That would be Roland and myself.
but, it also seems the original owner of the lib has disappeared from the list
Yes. Again, if anyone knows how to contact him, please do!
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?
I'm hoping so. At the very least I hope to fix any known or newly discovered bugs. Also, there are changes that William Kempf checked into the thread_dev branch in CVS before he disappeared from the list. I hope to incorporate these changes--or at least the ones that are already finished.
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. Thread cancellation or one of the other features William Kempf was working on may require some changes (I need to look into this), but I wouldn't expect any of them to require major changes. I've communicated with Roland privately, and the changes we are both most interested in (other than those listed above) are changes that build on the existing implementation rather than change it (e.g. new classes that use the existing ones). Most of the changes others have suggested to the Boost.Thread library from time to time also fall into this category.
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
Thanks!
burch
- - -
G. Burc ARPAT Ph.D. Candidate
Dept. of Petroleum Engineering Stanford University Stanford, CA 94305
Internet: www.burcarpat.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join():
try { thread.join(); } catch (std::runtime_error& e) { ... }
Any ideas?
Doesn't this require a certain amount of compiler support? IIRC, some compilers don't support throwing exceptions across thread boundaries...
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
IIRC, some compilers don't support throwing exceptions across thread boundaries...
Right. This can't be done portably. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
Why? Corba throws user exceptions across remote procedure calls without changes to the c++ compiler (of course there is an IDL compiler). Also, Rogue Wave has a portable library that does this for threading. In both cases the exception object is serialized across the thread/process boundary and then rethrown within the correct context. You can see more on this at http://www.roguewave.com/support/docs/sourcepro/threadsug/9-4.html
IIRC, some compilers don't support throwing exceptions across thread boundaries...
Right. This can't be done portably.
I assume you mean without library support and correctly written user code that uses the library? Jeff
Jeff Garland wrote:
On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
Why? Corba throws user exceptions across remote procedure calls without changes to the c++ compiler (of course there is an IDL compiler). Also, Rogue Wave has a portable library that does this for threading.
I think I agree with Jeff. Although without compiler support library code cannot propagate arbitrary exceptions across threads, we could manage to propagate exceptions declared ahead of time, possibly when thread object is created. Something along the lines of: boost::thread<runtime_error, ...> my_thread(functor); ...and later: try { my_thread.join() } catch (runtime_error&) { } catch (<any exception declared in type list above>&) { } I'm more uncertain how to approach the problem of (multiple) exceptions thrown in threads that are part of the single group.
IIRC, some compilers don't support throwing exceptions across thread boundaries...
I wouldn't expect compilers to do so. The needed support would have to come entirely from the library. Slawomir Lisznianski; [ www.rhapsodia.org ]
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
Why?
Because we don't have the luxury of an extra compilation stage like Corba does. There's no way to stop unwinding with catch(...), store whatever arbitrary exception object was thrown, and then rethrow it later.
IIRC, some compilers don't support throwing exceptions across thread boundaries...
Right. This can't be done portably.
I assume you mean without library support and correctly written user code that uses the library?
No, I mean without additional compilation resources not built into C++, or user registration of all possible exception types that can emanate from a thread. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 08 Feb 2004 15:28:08 -0500, David Abrahams wrote
Because we don't have the luxury of an extra compilation stage like Corba does. There's no way to stop unwinding with catch(...), store whatever arbitrary exception object was thrown, and then rethrow it later.
Corba doesn't really solve the problem with compilation, it just makes it easier for the user by generating binding code. The user has to derive from Corba::UserException to make it work. So, I wasn't suggesting that this would work with catch(...). Rather there would be a rethrowable_exception class that users would derive from to obtain this behavior. Which is like the Rogue Wave solution I pointed to...
No, I mean without additional compilation resources not built into C++, or user registration of all possible exception types that can emanate from a thread.
Yes, registration would be required by a factory object to unserialize the exception, construct, and rethrow on the other side of the thread boundary. Anyway, I believe all of this can be done (and has already) without changes to the langauge and would be portable. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 08 Feb 2004 15:28:08 -0500, David Abrahams wrote
Because we don't have the luxury of an extra compilation stage like Corba does. There's no way to stop unwinding with catch(...), store whatever arbitrary exception object was thrown, and then rethrow it later.
Corba doesn't really solve the problem with compilation, it just makes it easier for the user by generating binding code.
Code generation == an extra compilation stage. -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of David Abrahams Sent: Monday, February 09, 2004 9:28 AM To: boost@lists.boost.org Subject: [boost] Re: future of boost.threads
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
Christopher Currie <christopher@currie.com> writes:
<snip>
Why?
Because we don't have the luxury of an extra compilation stage like Corba does. There's no way to stop unwinding with catch(...), store whatever arbitrary exception object was thrown, and then rethrow it later.
I'm guessing this is a reference to IDL compilation? I see that generally Boost does not make use of code generators (i.e. something that fits into a build procedure like "yacc"). It does (brilliantly) use "code generation" from MPL lists but that's something else. I'm sure everyone understands this already but just had to show that I did also :-) Out of curiosity; is this a Boost policy? I vaguely thought I had read some Boost library requirements along these lines but now cant find them. Help? <snip>
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Cheers, Scott
Jeff Garland wrote:
On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
Why? Corba throws user exceptions across remote procedure calls without changes to the c++ compiler (of course there is an IDL compiler).
I see two different uses here for exceptions that seem to get lumped together: one is the controlled stack unwinding, i.e. the typical usage of exceptions in a single thread / single address space. The other is a means of communication that could even be used for 'higher level call stacks' such as in CORBA. The case of CORBA is particularly interesting as it tries to let the user believe he runs a conventional synchronous work flow when the ORB really deals with asynchronous message calls internally: when you call a method that (internally) gets dispatched to another address space the ORB blocks the current thread until it gets back the result (either return value or failure, which will be mapped back into an exception in the C++ mapping). So the question seems to me: what do you gain in a multi-threaded application to report thread execution failure as an exception to the main thread (the one calling 'join') ? While it seems entirely possible to declare some exception types that are throwable across threads (in the same way there are CORBA::Exceptions that can be exchanged across ORBs), I don't really see why a generic threading library should provide such a facility. It can always be added on a higher level that wraps the 'join()' call. Regards, Stefan
On Sun, 08 Feb 2004 16:11:03 -0500, Stefan Seefeld wrote
So the question seems to me: what do you gain in a multi-threaded application to report thread execution failure as an exception to the main thread (the one calling 'join') ?
You don't have to revert to C style error handling and pass error return codes from threads.
While it seems entirely possible to declare some exception types that are throwable across threads (in the same way there are CORBA::Exceptions that can be exchanged across ORBs), I don't really see why a generic threading library should provide such a facility.
Rogue Wave seems to disagree and has built this directly into their threading package. It is a pure C++ example that I think you'all missed in the first email... http://www.roguewave.com/support/docs/leif/foundation/html/threadsug/9.html http://www.roguewave.com/support/docs/leif/foundation/html/threadsug/booktoc... Of course this doesn't prove it is useful, but it's mere existance in a cross-platform C++ library does show it can be done.
It can always be added on a higher level that wraps the 'join()' call.
This might be true, but I would think the exception abstractions and framework would need to be part of the library. If you look at the RW docs you there are some examples that show they build it in at this level. It looks something like: ThreadFunction someThread = ...; try { someThread.start(); // Start the thread someThread.join(); someThread.raise(); // Rethrow any exception that was caught! } catch(rethrowable_exception& msg) { cout << "Exception! " << msg.why() << endl; } I'm not trying to argue that this should be the focus of boost::threads, just that I wouldn't dismiss the potential need. There are lots of other things that boost.threads lacks when stacked up against more comprehensive solutions which are probably more important than cross-thread exceptions... Jeff
Jeff Garland wrote:
It can always be added on a higher level that wraps the 'join()' call.
This might be true, but I would think the exception abstractions and framework would need to be part of the library. If you look at the RW docs you there are some examples that show they build it in at this level. It looks something like:
ThreadFunction someThread = ...; try { someThread.start(); // Start the thread someThread.join(); someThread.raise(); // Rethrow any exception that was caught! } catch(rethrowable_exception& msg) { cout << "Exception! " << msg.why() << endl; }
for this to work you'd need a way to marshall exceptions from one thread to another, which imposes some constraints on the exception types to be thrown. A similar problem arises when C++ code is used to wrap a C 'middleware' library, where you want to pass through exceptions from C++ callbacks to the C++ application. I'v seen examples where the C++ wrapper code defines its own exception types that provide 'clone()' methods so they could be stored and rethrown in a different context. I'm curious to learn whether the boost experts have better techniques to deal with these situations. Regards, Stefan
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types. This problem needs to be addressed in the context of delayed calls (or whatever the current phrase if for it) where you curry the arguments now, save the call for later dispatch and do it later (and maybe even return a value). We managed to solve this problem for each of the exceptions mentioned in Josuttis 1st edition plus all of the implicit types and one of our library's exceptions (derived from std::runtime_error which supported an error_number in addition to what()). We solved this for a message passing system. The exceptions came back when you waited for a reply to a message. The code wasn't great, but it did the job, and since exceptions were rare (exceptional one might say) the hit on performance was unnoticeable, but it certainly made writing the programs somewhat simpler. I believe the same approach could be taken with threads & join(). Will it solve everything? No. Will it solve may of the things people want to do? I believe so. How much will it affect the runtime? That depends on the exception handling capabilities of the system. In particular we had, iirc, about 20 catch() clauses after the try around the call to the "dispatchThisMessage()" call. At Sunday 2004-02-08 09:23, you wrote:
Christopher Currie <christopher@currie.com> writes:
Slawomir Lisznianski wrote:
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with proposals varying from Futures to throwable join(): try { thread.join(); } catch (std::runtime_error& e) { ... } Any ideas?
Doesn't this require a certain amount of compiler support?
Yes.
IIRC, some compilers don't support throwing exceptions across thread boundaries...
Right. This can't be done portably.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner, Jr." <vawjr@rudbek.com> writes:
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types.
And what if the std library or somebody else throws exceptions *derived* from the standard types? -- Dave Abrahams Boost Consulting www.boost-consulting.com
At Monday 2004-02-09 07:56, you wrote:
"Victor A. Wagner, Jr." <vawjr@rudbek.com> writes:
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types.
And what if the std library or somebody else throws exceptions *derived* from the standard types?
I guess I should have said _are_ standard types We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions). I suggest "something" as a useful approach.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
There are better ways. Boost.Python uses a dynamic registration technique. Compile-time enumeration of the exceptions is overkill and not sufficiently flexible. -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
There are better ways. Boost.Python uses a dynamic registration technique.
Do you think that this technique could be factored out to solve the problem with threads? Another problem I've had to deal with is propagating exceptions through windows message handlers.
Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
If anything I'd say compile-time enumerations is underkill. Typically I'd only be interested in one or two types of exceptions and something like this: run_and_throw<my_lib::socket_error, std::exception>(f); Or maybe something like lambda::try_catch seems much simpler than anything involving dynamic registration. On the other hand, I agree that it's not as flexible. Are you referring to the problem with splicing in particular? Brock
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
There are better ways. Boost.Python uses a dynamic registration technique.
Do you think that this technique could be factored out to solve the problem with threads?
Sure; it would be easy.
Another problem I've had to deal with is propagating exceptions through windows message handlers.
I'm not sure what the issues there are.
Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
If anything I'd say compile-time enumerations is underkill. Typically I'd only be interested in one or two types of exceptions and something like this:
run_and_throw<my_lib::socket_error, std::exception>(f);
Or maybe something like lambda::try_catch seems much simpler than anything involving dynamic registration. On the other hand, I agree that it's not as flexible. Are you referring to the problem with splicing in particular?
Splicing? No, I'm referring to the great deal of compile-time machinery needed to generate a structure which can ultimately be done nearly as efficiently at runtime. Generally if you have a bunch of interacting libraries it makes sense for each one to be able to register its exception serializers/deserializers/translators or whatever. Why should the thread invoker have to enumerate the possibilities each time? -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
No, I'm referring to the great deal of compile-time machinery needed to generate a structure which can ultimately be done nearly as efficiently at runtime.
I'm not concerned about efficiency so much as ease of use. How do you register an exception class? Does it have to be derived from a base class in the library?
Generally if you have a bunch of interacting libraries it makes sense for each one to be able to register its exception serializers/deserializers/translators or whatever. Why should the thread invoker have to enumerate the possibilities each time?
The invoker could store often used lists in typedefs. They could easily add or remove exceptions from these. I agree that it could be messy and hard on the compiler for larger lists. Personally I've never been interested in more than one or two types of exceptions at a time though.
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
No, I'm referring to the great deal of compile-time machinery needed to generate a structure which can ultimately be done nearly as efficiently at runtime.
I'm not concerned about efficiency so much as ease of use. How do you register an exception class?
http://boost-consulting.com/boost/libs/python/doc/v2/exception_translator.ht...
Does it have to be derived from a base class in the library?
No.
Generally if you have a bunch of interacting libraries it makes sense for each one to be able to register its exception serializers/deserializers/translators or whatever. Why should the thread invoker have to enumerate the possibilities each time?
The invoker could store often used lists in typedefs. They could easily add or remove exceptions from these.
That doesn't sound like ease-of-use to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
Generally if you have a bunch of interacting libraries it makes sense for each one to be able to register its exception serializers/deserializers/translators or whatever. Why should the thread invoker have to enumerate the possibilities each time?
The invoker could store often used lists in typedefs. They could easily add or remove exceptions from these.
That doesn't sound like ease-of-use to me.
Just to prove to myself that I could do it I implemented a rough version of what I was talking about. I think the interface is pretty easy to use. exception_transporter.h - non thread related tool for transporting exceptions in a typelist. Could be used for other areas where exceptions propagation is an issue. Returns exceptions in a variant so the user can inspect or throw them. thread_with_exceptions.h - used like: thread_with_exceptions<exception_type_list, return_type> t(thread_function); //may propagate an exception from the list return_type rval = t.join(); main.cpp - implements a small example. Does this seem like a reasonable approximation of what people have been asking for? I think there needs to be a way to say "catch all exceptions derived from X and transport them as Y, using F to construct the Y's". Like "catch all exceptions derived fro std::exception and transport them as std::runtime_error by passing what() to std::runtime_error's constructor".
On Wed, 11 Feb 2004 13:26:27 -0600, Brock Peabody <brock.peabody@npcinternational.com> wrote:
Just to prove to myself that I could do it I implemented a rough version of what I was talking about. I think the interface is pretty easy to use.
exception_transporter.h - non thread related tool for transporting exceptions in a typelist. Could be used for other areas where exceptions propagation is an issue. Returns exceptions in a variant so the user can inspect or throw them.
thread_with_exceptions.h - used like:
thread_with_exceptions<exception_type_list, return_type> t(thread_function);
//may propagate an exception from the list return_type rval = t.join();
main.cpp - implements a small example.
Does this seem like a reasonable approximation of what people have been asking for?
All looks fine to me, but without meaning to sound rude, what does it give you over the implementation I posted two days ago? Sam
Sam Partington <Sam.Partington@metagence.com> writes:
On Wed, 11 Feb 2004 13:26:27 -0600, Brock Peabody <brock.peabody@npcinternational.com> wrote:
Just to prove to myself that I could do it I implemented a rough version of what I was talking about. I think the interface is pretty easy to use.
exception_transporter.h - non thread related tool for transporting exceptions in a typelist. Could be used for other areas where exceptions propagation is an issue. Returns exceptions in a variant so the user can inspect or throw them.
thread_with_exceptions.h - used like:
thread_with_exceptions<exception_type_list, return_type> t(thread_function);
//may propagate an exception from the list return_type rval = t.join();
main.cpp - implements a small example.
Does this seem like a reasonable approximation of what people have been asking for?
All looks fine to me, but without meaning to sound rude, what does it give you over the implementation I posted two days ago?
And what about the one Daniel Wallin posted, which doesn't require all exceptions to be registered in one big compile-time list? -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
And what about the one Daniel Wallin posted, which doesn't require all exceptions to be registered in one big compile-time list?
I'd rather be able to put them all in a list than to have to manually register each one. However, given a runtime registration mechanism I guess it shouldn't be too difficult to implement a compile to interface on top and it would probably compile faster than a version implemented completely at compile time. Brock
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
On Behalf Of David Abrahams
And what about the one Daniel Wallin posted, which doesn't require all exceptions to be registered in one big compile-time list?
I'd rather be able to put them all in a list than to have to manually register each one.
?? it seems equivalent to me.
However, given a runtime registration mechanism I guess it shouldn't be too difficult to implement a compile to interface on top and it would probably compile faster than a version implemented completely at compile time.
Yup. More importantly, it works even if different libraries register separate translators for exceptions in the same class hierarchy, without regard to registration order. -- Dave Abrahams Boost Consulting www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
I'd rather be able to put them all in a list than to have to manually register each one.
?? it seems equivalent to me.
Maybe I'm too lazy, but <exception1, exception2, ... > is a little more compact than register_<exception1>(); register_<exception2>(); ...
However, given a runtime registration mechanism I guess it shouldn't be too difficult to implement a compile to interface on top and it would probably compile faster than a version implemented completely at compile time.
Yup. More importantly, it works even if different libraries register separate translators for exceptions in the same class hierarchy, without regard to registration order.
That's one thing I guess I'm missing - where would the runtime register live? In Daniel Wallin's implementation it the register was a singleton, but wouldn't you want a separate register for each thread/thread_group? Brock
Brock Peabody wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
I'd rather be able to put them all in a list than to have to manually register each one.
?? it seems equivalent to me.
Maybe I'm too lazy, but
<exception1, exception2, ... >
is a little more compact than
register_<exception1>(); register_<exception2>(); ...
Well, register_<exception1, exception2, ...>(); isn't that hard to implement. But that's not really the point. The point is that you can place the register_ calls in multiple translation units, and you can register_ your library's exceptions even if you don't create any threads, and you don't expose their actual types to the world.
Yup. More importantly, it works even if different libraries register separate translators for exceptions in the same class hierarchy, without regard to registration order.
That's one thing I guess I'm missing - where would the runtime register live? In Daniel Wallin's implementation it the register was a singleton, but wouldn't you want a separate register for each thread/thread_group?
No, not really. There are two related, but distinct, notions that are being mixed up, "how" to transport exception X, and "whether" to transport exception X from the thread procedure to the join point. The ability to transport an exception is not coupled to any thread, or to a particular thread library, for that matter. You need to be able to copy the exception and to throw it at run time without having access to its type. When we discussed the issue I proposed that exceptions derived from: struct transportable_exception { virtual auto_ptr<transportable_exception> clone() const = 0; virtual void rethrow() const = 0; }; be automatically transportable without any registration; a helper template<class E> void throw_transportable_exception(E const & e); can take care of injecting the base class automatically. This can, of course, be combined with an explicit register_<>, and all standard library exceptions need also be transportable by default, without registration. A generic unregistered std::exception should, as you pointed out, be converted to unknown_exception with the what() string preserved. That's the "how" part. The "whether" part is that we (arguably) need the ability to specify a list of "expected" exception base classes at thread creation time. I'm still not sure about that, since this is for all intents and purposes an exception specification. Much the same effect can be achieved by just decorating the thread function with one.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
register_<exception1, exception2, ...>();
isn't that hard to implement. But that's not really the point. The point is that you can place the register_ calls in multiple translation units, and you can register_ your library's exceptions even if you don't create any threads, and you don't expose their actual types to the world.
Yes, as you point out below I was confusing registration with listing expected exceptions. In the implementation I was thinking of there really is no registration.
That's the "how" part.
Thanks, that is much clearer now.
The "whether" part is that we (arguably) need the ability to specify a list of "expected" exception base classes at thread creation time. I'm still not sure about that, since this is for all intents and purposes an exception specification. Much the same effect can be achieved by just decorating the thread function with one.
With a global register and no expected exception list, won't it be possible for changes in one part of the program to affect which exceptions are propagated into the calling thread in another part of the program? Is that good or bad? If there is an excepted exception list, do you think it makes sense to have the library automatically register the types in this list? Brock
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
The "whether" part is that we (arguably) need the ability to specify a
Brock Peabody wrote: list
of "expected" exception base classes at thread creation time. I'm still not sure about that, since this is for all intents and purposes an exception specification. Much the same effect can be achieved by just decorating the thread function with one.
With a global register and no expected exception list, won't it be possible for changes in one part of the program to affect which exceptions are propagated into the calling thread in another part of the program? Is that good or bad?
It can be both good and bad, depending on... I could say "the design", but it mostly depends on the design philosophy. I think that it's neutral, and just mirrors how exceptions work when threads are not part of the equation. Clearly, changes of parts of the program can affect which exception is propagated to other parts of the program. As long as the other parts are not hardwired to expect a particular kind of failure, all will be fine and well. This is particularly relevant when you control the throw point and the catch point, but not what is between them; one simple example is when you pass a throwing function to std::for_each. The main danger I see is not when join() throws an "unexpected" exception, but when join() is not called at all. This is bad; without threads an exception annoys functions up the call stack until someone accepts the responsibility to handle it, but without a join(), the thread exception will be lost silently. I'm not sure how this can be fixed; calling terminate() when the last reference to the thread goes away seems rather drastic, but may prove necessary.
If there is an excepted exception list, do you think it makes sense to have the library automatically register the types in this list?
Possibly, but I'm not sure how useful that would be. I'd usually only put abstract base classes in that list. :-)
Peter Dimov wrote: [...]
The main danger I see is not when join() throws an "unexpected" exception ...
Actually, join() and result() should be separate operations. First, join() can probably fail with an exception, and second, in a thread group we'd like to be able to first join all threads and then examine the results one by one. result() can still automatically join() if necessary, but a separate join() needs to be present.
-----Original Message----- On Behalf Of Peter Dimov
It can be both good and bad, depending on... I could say "the design", but it mostly depends on the design philosophy. I think that it's neutral, and just mirrors how exceptions work when threads are not part of the equation. Clearly, changes of parts of the program can affect which exception is propagated to other parts of the program. As long as the other parts are not hardwired to expect a particular kind of failure, all will be fine and well.
That's true. I'm still a little uncomfortable with the idea of a static register though. How, for instance, would you share a register between dynamic link libraries if the register is static?
The main danger I see is not when join() throws an "unexpected" exception, but when join() is not called at all. This is bad; without threads an exception annoys functions up the call stack until someone accepts the responsibility to handle it, but without a join(), the thread exception will be lost silently. I'm not sure how this can be fixed; calling terminate() when the last reference to the thread goes away seems rather drastic, but may prove necessary.
I think it would be better than a silent failure.
If there is an excepted exception list, do you think it makes sense to have the library automatically register the types in this list?
Possibly, but I'm not sure how useful that would be. I'd usually only put abstract base classes in that list. :-)
Now I'm confused again :) My understanding was that there is no way to transport a user defined abstract base class unless you derive it from transportable_exception, in which case it wouldn't need to be registered at all. My list would almost always be either just std::exception - so I could log/report what happened before terminating - and/or some concrete base that I don't mind slicing. Brock
Brock Peabody wrote:
That's true. I'm still a little uncomfortable with the idea of a static register though. How, for instance, would you share a register between dynamic link libraries if the register is static?
I may or may not be right, but I don't expect this problem to occur frequently in practice, if the recommendation is to use throw_transportable_exception, with register_ only being used when it is not possible to modify the throw statement. The architecture I'm picturing in my mind differs slightly from your implementation (and probably Sam's, I haven't had time to look at it). I envisage a (reusable, perhaps) exception translator that catches all registered and standard exceptions, wraps them in a new shiny transportable_exception package, and rethrows, something like template<class F> void translate_exceptions(F f) { try { f(); } catch(transportable_exception const &) { throw; } catch(registered_exception_1 const & e) { throw_transportable_exception(e); } // and so on } with the optional< variant<R, ...> > of your implementation replaced by an optional<R>, auto_ptr<transportable_exception> pair. The unfortunate author of a DLL that calls sourceless throwing functions but needs to register_ exceptions can just wrap the functions in his own exception translator, if all else fails. We may even provide a generator exception_translator_generator<X1, X2, ..., Xn>::translate(f);
If there is an excepted exception list, do you think it makes sense to have the library automatically register the types in this list?
Possibly, but I'm not sure how useful that would be. I'd usually only put abstract base classes in that list. :-)
Now I'm confused again :) My understanding was that there is no way to transport a user defined abstract base class unless you derive it from transportable_exception, in which case it wouldn't need to be registered at all.
I'm just saying that I'd probably use the expected list strictly as a "whether" mechanism, as I'd prefer to specify the "how" only once, not per thread creation point. But that's just my opinion.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
I envisage a (reusable, perhaps) exception translator that catches all registered and standard exceptions, wraps them in a new shiny transportable_exception package, and rethrows, something like
Surely it wouldn't be a problem to make this translator available as a free-standing class as well as a singleton instance.
The unfortunate author of a DLL that calls sourceless throwing functions but needs to register_ exceptions can just wrap the functions in his own exception translator, if all else fails. We may even provide a generator
exception_translator_generator<X1, X2, ..., Xn>::translate(f);
Really, this simple interface can satisfy 95% of my exception transporting needs. I usually just want to know if an exception was derived from X and/or what it's error text is. Provided that X is concrete I can get this without registration or changing the code that throws. Users with more sophisticated needs have the capability to register exceptions or derive them from transportable_exception. We all win? I understand that you and Dave see it as less simple to specify the exceptions at thread creation time but in my situation it's the easiest way. Our software is split into many small discreet libraries, static and shared. None of these libraries can make any assumptions about who has or hasn't registered exceptions so they're all going to have to do it every time anyway. Also, I'm almost never interested in the "type" of more than one exception so making the list isn't be a chore.
I'm just saying that I'd probably use the expected list strictly as a "whether" mechanism, as I'd prefer to specify the "how" only once, not per thread creation point. But that's just my opinion.
I can understand not wanting to confuse the issues "how" and "whether", but for many simple cases they will be the same. On the other hand, I agree with you in doubting whether or not we really need a "whether" anyway. Brock
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Sam Partington
All looks fine to me, but without meaning to sound rude, what does it give you over the implementation I posted two days ago?
Nothing, I'm sorry but I guess that message slipped by me. It was a fun exercise though.
A meta issue: Does anyone else has this partly stochastic order of postings? I am trying to build the, hopefully acyclic, reference graph mentally as I read the postings... That Brock and I exposed the almost exact same (stupid?) typelist idea at the same time is also intriguing... /David
At Monday 2004-02-09 14:18, you wrote:
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
There are better ways. Boost.Python uses a dynamic registration technique. Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
I'm all ears to hear about runtime exception detection and classification what syntax for the compiletime catch() do you expect to use?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner, Jr." <vawjr@rudbek.com> writes:
At Monday 2004-02-09 14:18, you wrote:
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
There are better ways. Boost.Python uses a dynamic registration technique. Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
I'm all ears to hear about runtime exception detection and classification what syntax for the compiletime catch() do you expect to use?
Use the source, Luke. It's all there in your CVS snapshot. Doesn't handle ordering of base and derived classes, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
There are better ways. Boost.Python uses a dynamic registration technique. Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
Isn't there a problem with ordering in hierarchies when using dynamic registration? register_exception<std::exception>(); register_exception<my_exception>(); vs register_exception<my_exception>(); register_exception<std::exception>(); AFAICT there is no way to determine the most derived type. Maybe this isn't a problem in practice.. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote
AFAICT there is no way to determine the most derived type.
There is. Relation between types is stored in application in order to enable exception catching mechanism. If you throw pointer to type T during runtime, you can find if it is most derived than other types. You need to generate all combinations of catch clauses and try them all. It is rather slow but tricks can be used to sped it up. /Pavel
Pavel Vozenilek wrote:
"Daniel Wallin" <dalwan01@student.umu.se> wrote
AFAICT there is no way to determine the most derived type.
There is. Relation between types is stored in application in order to enable exception catching mechanism.
If you throw pointer to type T during runtime, you can find if it is most derived than other types. You need to generate all combinations of catch clauses and try them all. It is rather slow but tricks can be used to sped it up.
You are right, very cool! -- Daniel Wallin
At Monday 2004-02-09 23:33, you wrote:
David Abrahams wrote:
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
There are better ways. Boost.Python uses a dynamic registration technique. Compile-time enumeration of the exceptions is overkill and not sufficiently flexible.
Isn't there a problem with ordering in hierarchies when using dynamic registration?
register_exception<std::exception>(); register_exception<my_exception>();
vs
register_exception<my_exception>(); register_exception<std::exception>();
AFAICT there is no way to determine the most derived type. Maybe this isn't a problem in practice..
that was the algorithm that I thought I'd remembered from Alexandrescu's tome. I have a meeting in a few minutes, I'll try to look it up when I return.
-- Daniel Wallin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
I recently spent some time thinking about a similar problem, and after looking at transporting exceptions for some time, I decided that it's a big pain for a variety of reasons (all of which have been mentioned in this thread already), and that the interface would not be particularly pleasant (what with having to register exceptions types from every 3rd party C++ library that I use), so I am currently considering an alternate approach: having an object whose responsibility it is to handle exceptions in the appropriate way, and passing that object around. When I need to handle an exception, instead of trying to teleport the exception out of the C++ exception handling mechanism, I'd simply tell that object to handle the current exception in whatever manner it seems fit. Something along the lines of: void my_thread_main { ... catch (...) { current_exception_handler(get_current_thread())->handle_current_exception(); } } Here I assume that my thread model gives me a way to get at the current thread, and that it gives me a way to have some thread local data in which I can stash a copy of the current thread exception handler. handle_current_exception would then use the standard rethrow/catch technique to get at the exception: void my_exception_handler::handle_current_exception() { try { throw; } catch (std::exception& e) { ... } ... } This mechanism also allows for a hierarchy of exception handling policies. For example, the top level of the application creates an exception handling object with a sensible default behavior. When the application enters a state in which a more specific exception handling behavior is desirable, the per-thread exception handling object is set to some object that understands the more specific context. The more specific object, when created, obtains a reference to the more generic one, and calls through to it when it doesn't know what to do with an exception: void my_exception_handler::handler_current_exception() { try { try { throw; } catch (my_exception) { if (know how to handle) { // ... } else { throw; } } } catch (...) { next_exception_handler()->handle_current_exception(); } } (The double try makes sure that any exceptions rethrown by the inner handler are propagated to the next handler in the chain.) This is an idea that has only recently started brewing in my head -- so recently that I haven't actually had the time to implement it -- so I am quite aware that there may be something that I am missing. However, it does have all the properties that I want in my exception handling: - the exception handling policy is specified orthogonally to non-exception flow - the exception handling policy is specifed by the code that will handle the error, not by the code that generates the error - exception handling policies can be layered in a hierarchy that corresponds to user actions (even when the hierarchy of user actions does not directly correspond to the machine stack -- e.g. with threads, or various message and event passing architectures). - it does not require me to solve the problem of transporting exceptions I find myself wondering why an architecture of this kind is not being considered in the current discussion. meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
Miro Jurisic <macdev@meeroh.org> writes:
This mechanism also allows for a hierarchy of exception handling policies. For example, the top level of the application creates an exception handling object with a sensible default behavior. When the application enters a state in which a more specific exception handling behavior is desirable, the per-thread exception handling object is set to some object that understands the more specific context. The more specific object, when created, obtains a reference to the more generic one, and calls through to it when it doesn't know what to do with an exception:
void my_exception_handler::handler_current_exception() { try { try { throw; } catch (my_exception) { if (know how to handle) { // ... } else { throw; } } } catch (...) { next_exception_handler()->handle_current_exception(); } }
(The double try makes sure that any exceptions rethrown by the inner handler are propagated to the next handler in the chain.)
This is much more complicated than the solution cited earlier in the thread that is already in Boost.Python, and less portable too because many compilers have trouble with try { throw; }... -- Dave Abrahams Boost Consulting www.boost-consulting.com
In article <uisi91p0k.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
many compilers have trouble with try { throw; }...
I was not aware of this. Thanks. meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
At Monday 2004-02-09 10:57, you wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner, Jr.
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
I'd suggest allowing the user to specify a typelist rather than hard coding the standard types. You could supply as a default the list of standard types.
Fine, _I_ know how to save, then restore and throw the stuff I suggested. I don't have a clue for handling typelist. If you want that done, you'll have to find another implementor.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor wrote:
At Monday 2004-02-09 07:56, you wrote:
"Victor A. Wagner, Jr." <vawjr@rudbek.com> writes:
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types.
And what if the std library or somebody else throws exceptions *derived* from the standard types?
I guess I should have said _are_ standard types
Or, at least _are_ in the sense of being equivalent under slicing...
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
Whimsical idea: could we use type lists, so we could instantiate a thread starter template with the list of exceptions it should wrap, and get slicing semantics into the calling context? All other exceptions would fall through, but then the user can enumerate the "most possible" exceptions. /David
At Monday 2004-02-09 10:57, you wrote:
Victor wrote:
At Monday 2004-02-09 07:56, you wrote:
"Victor A. Wagner, Jr." <vawjr@rudbek.com> writes:
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types.
And what if the std library or somebody else throws exceptions *derived* from the standard types?
I guess I should have said _are_ standard types
Or, at least _are_ in the sense of being equivalent under slicing...
We can either do nothing (until the standard changes so we can handle ALL types) or we can do something (handle the built-in types and the standard exceptions).
I suggest "something" as a useful approach.
Whimsical idea: could we use type lists, so we could instantiate a thread starter template with the list of exceptions it should wrap, and get slicing semantics into the calling context? All other exceptions would fall through, but then the user can enumerate the "most possible" exceptions.
my recollection of writing the handlers we did write was that we had to be quite careful about the order in which we did the catch phrases. But I sort of remember Andrei having a way of mutating a type list such that they were in such an order (wasn't that one of his algorithms in the book?) I'd love to _learn_ how to do such a thing.
/David
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Are there any plans to support handling of exceptions thrown during joinable thread execution? I recall Usenet discussions with
varying from Futures to throwable join():
try { thread.join(); } catch (std::runtime_error& e) { ... }
Any ideas?
On Thu, 5 Feb 2004 09:59:03 -0500, "Michael Glassford" <glassfordm@hotmail.com> said:
"Burc Arpat" <burch@stanford.edu> wrote in message news:loom.20040205T111202-673@post.gmane.org...
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
and from what
i gathered there are plans to start working on it again.
That would be Roland and myself.
but, it also seems the original owner of the lib has disappeared from the list
Yes. Again, if anyone knows how to contact him, please do!
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?
I'm hoping so. At the very least I hope to fix any known or newly discovered bugs. Also, there are changes that William Kempf checked into the thread_dev branch in CVS before he disappeared from the
I remember very long and involved discussions, but don't remember any consensus being reached or any resolution being found to the difficult issues involved. Am I mistaken? Mike "Slawomir Lisznianski" <slisznianski@asyncnet.com> wrote in message news:20040205190629.08537154D84@mail.messagingengine.com... proposals library list.
I hope to incorporate these changes--or at least the ones that are already finished.
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. Thread cancellation or one of the other features William Kempf was working on may require some changes (I need to look into this), but I wouldn't expect any of them to require major changes. I've communicated with Roland privately, and the changes we are both most interested in (other than those listed above) are changes that build on the existing implementation rather than change it (e.g. new classes that use the existing ones). Most of the changes others have suggested to the Boost.Thread library from time to time also fall into this category.
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
Thanks!
burch
- - -
G. Burc ARPAT Ph.D. Candidate
Dept. of Petroleum Engineering Stanford University Stanford, CA 94305
Internet: www.burcarpat.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
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). Regards, m
"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
participants (17)
-
Brock Peabody -
Burc Arpat -
Christopher Currie -
Daniel Wallin -
David Abrahams -
David Bergman -
Jeff Garland -
Martin Wille -
Michael Glassford -
Miro Jurisic -
Pavel Vozenilek -
Peter Dimov -
Sam Partington -
scott -
Slawomir Lisznianski -
Stefan Seefeld -
Victor A. Wagner, Jr.