[dmd-concurrency] draft 5

Andrei Alexandrescu andrei at erdani.com
Tue Jan 19 21:49:23 PST 2010


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.

Andrei

Kevin Bealer wrote:
> On Tue, Jan 19, 2010 at 5:30 AM, Andrei Alexandrescu <andrei at erdani.com 
> <mailto:andrei at erdani.com>> wrote:
> 
>     I uploaded draft 5 here:
> 
> 
> I'm reading and just got to the section on shutdown protocol.
> 
> Will all threads be delivered a single shutdown exception, after which 
> they can do whatever they want, or will they get one every time they try 
> to do a receive?  The simple assumption is that you get all the shutdown 
> exceptions you can eat, but I can imagine a number of cases where "just 
> one" is better.  Consider a simple processing flow:
> 
> A -> B -> C
> 
> A is producing data, sending it along to B, which does calculations, and 
> sends them along to C.  C caches data up and stores data in a database 
> or the file-system.  B is doing intermediate processing of some kind.  
> Maybe A, B, and C are tiers of a web application.  Now everyone starts 
> getting shutdown exceptions.
> 
> Is there a way for B to send a final message to C (e.g. "save this draft 
> of an email"), or C to A (a polite apology 'technical difficulty' 
> message pulled from the database maybe)?  It seems like it would be nice 
> to have the messaging system when designing shutdown logic, even if main 
> is shutting down.
> 
> If you think about it, there is no utility in any shutdown exception 
> after the first one.  If a thread doesn't catch it, it will terminate as 
> expected.  But as soon as a thread is going to catch one such message, 
> then either it knows what it is doing or else it is already doomed in 
> some way, another message won't be any more help.
> 
> If messaging does not exist then each component is suddenly going to 
> need it's own filesystem or database persistence logic, which would 
> reduce the one-actor-one-responsibility principle of the design.
> 
> (But either way it would be neat if the draft said which happens.)
> 
> Kevin
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency


More information about the dmd-concurrency mailing list