[dmd-concurrency] draft 5

Sean Kelly sean at invisibleduck.org
Tue Jan 19 23:26:44 PST 2010


On Jan 19, 2010, at 11:13 PM, Andrei Alexandrescu wrote:

> Sean Kelly wrote:
>> On Jan 19, 2010, at 10:50 PM, Andrei Alexandrescu wrote:
>>> 
>>> If fnB does call concurrency-related routines, it must end when main() exits. To me exiting main() is a no-quarters situation: it means the application is to exit asap. I find it weird to think of programs that finish main() but continue to do stuff.
>> I feel somewhat the opposite.  If some random thread terminates abnormally, why does the app continue to run as if nothing happened?  I'd prefer for every thread, including main, to work exactly the same.
> 
> This equivalence sounds more like anarchy than democracy to me. Absent a "special" function, designing coherent shutdown becomes harder, not easier.

Hm... so let's presume for a moment that every kernel thread is multiplexing a bunch of user threads (fibers) behind the scenes.  In this instance, the main thread exits when all of its fibers exit?  Or I guess I should be thinking about this from a user code perspective, in which case it would be when execution passes beyond the scope of main(), regardless of what magic is actually happening in the runtime.  So to implement this, I guess I'd have to track which context represents the main thread so I can treat it differently... messy, but doable.

>>> To make sure everything is accounted for, the application design must be such that main() doesn't exit until useful threads are done.
>> Yeah, this just seems like it could be troublesome in large apps.
> 
> Well they haven't tried the Shutdown approach :o).

I really like what you described regarding types deriving from Exception... still not sure about this bit though :-)


More information about the dmd-concurrency mailing list