[dmd-concurrency] draft 5

Kevin Bealer kevinbealer at gmail.com
Tue Jan 19 21:45:03 PST 2010


On Tue, Jan 19, 2010 at 5:30 AM, Andrei Alexandrescu <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100120/dfc8518e/attachment-0001.htm>


More information about the dmd-concurrency mailing list