RE: [boost] Re: Re: Re: Threads & Exceptions

From: Darryl Green (green_at_[hidden])
Date: 2002-08-08 21:36:55

> -----Original Message-----
> From: Eric Woodruff [mailto:Eric.Woodruff_at_[hidden]]
> Maybe the problem is there are few high-level multi-threading 
> concepts, if
> any.

Not true.

> Most things are low-level like mutexes and threads. If 
> there was a
> better way to describe the synchronicity of a system.

There are better ways (at least for some problem domains) but I'm not really
seeing the point here. We were discussing the very low level things
(threads) in a C++ environment. A lot of C++ code already uses threads.
Profligate thread usage seems to be positively encouraged on at least one
rather widely used platform. As is (possibly) implied by your reference to a
"better way" a lot of C++ apps using threads don't really need them - or at
least not explicitly - and would be better written using concepts similar to
those used in (say) erlang or maybe uC++. In turn, these might (on some
platforms/sometimes the app author needn't know or care) use threads and the
necessary primitives to synchronise and pass data between them. This brings
us back to how such a high level model would deal with C++ exceptions,
especially if the app doesn't entirely follow the model (eg. 3rd party libs
used).

Basically, I think the whole "main is special" thing is a nuisance that has
to be lived with. However, as I understand it, there isn't really anything
special about the "main thread" only about the main function (specifically,
exiting it)? We obviously cant break existing code that relies on this
behaviour, but I think we can assume that the app developer "owns" main()
and can stick a catch (...) there at least. It is the other threads that are
harder to control... Assuming we do actually get to the point of allowing
threads to terminate due to an uncaught exception without terminating the
whole process, the issue of just how to deal with this (which thread(s) get
notified? how? when?) remains an issue, and a more interesting one than this
tedious stuff about having to call terminate() :-)

> compiler could
> even generate the thread_terimate ()s, etc.

Im not sure what you are getting at here? It sounds even further beyond what
a library can do than musings on thread_terminate etc?