[dmd-concurrency] draft 5

[Andrei Alexandrescu]

That would certainly work, but honest to God I am completely infatuated 
with the proposed model. It's simple, no need for a new "daemon" 
concept, and avoids very easily and elegantly the unpleasant zombie 
situation when main has finished but is somewhere in limbo mode hoping 
for some other thread to end.

Also, look at how simple it makes all examples. It's a dream come true. 
I've been thinking of a correct shutdown protocol for years, and this is 
better than anything I've ever tried.

I'd be ok with doing what Java does if we find an Achilles' heel of the 
current model. If not, I suggest we go with it and let users handle 
their own daemons (heh) in main().


Andrei

Sean Kelly wrote:
> On Jan 19, 2010, at 9:49 PM, Andrei Alexandrescu wrote:
> 
>> Sorry, I was unclear on that. Once the application is shutting down, any call to concurrency-related function, pending or new, will result in the Shutdown exception.
> 
> Why couldn't any threads that cared simply watch() the main thread so they'll be notified when it terminates?  Forcing this behavior on the user means that if an app wants to do anything in a separate thread that doesn't communicate with the main thread, he'd have to make sure the main thread joined every other thread in the process to keep from interrupting it.
> 
> Druntime follows the Java model of having an isDaemon field on the Thread object.  If isDaemon is false for a thread T1 then the main thread will silently wait for T1 to terminate before shutting down the app.  If isDaemon is true however, T1 will be terminated forcibly by the OS as the process exits.  Perhaps we could provide this ShutdownException behavior only to daemon threads as a replacement for the messy shutdown they have now?
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency