[dmd-concurrency] draft 5

Kevin Bealer kevinbealer at gmail.com
Tue Jan 19 22:37:17 PST 2010


On Wed, Jan 20, 2010 at 1:28 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> 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
>
>
I really like the exception concept, by the way.  But I still think that if
there is no way to send normal messages once the shutdown phase begins, you
will see a small crop of schemes for sending messages in some other way to
coordinate shutdown.  (Moreso on network based systems which tend to have
sharper division of 'ownership of role'.)  I've been on a team that had to
invent such things ourselves.

Kevin


>
> 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
>>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100120/e81ce795/attachment.htm>


More information about the dmd-concurrency mailing list