[dmd-concurrency] draft 5

[Kevin Bealer]

On Tue, Jan 19, 2010 at 5:30 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> Apparently I can't convince Brad that I'm not spamming - my attachments
> keep on being delayed through moderation because they're too big.
>
> I uploaded draft 5 here:
>
> www.erdani.com/d/fragment.preview.pdf
>
> Again: Don't re-read what you've already read, move forward. Feedback
> would be appreciated. Sean, Walter, please let me know quickly if you
> see any major implementation issues.
>
>
> Thanks,
>
> Andrei
>
>
Other question: setMaxMailboxSize sets the mailbox size on the caller, so...

1. It only affects that caller?  Others can set their own policy and use a
bigger size or no limit?  If so, this seems to act as a kind of message
priority thing.

2. If it measures messages from any caller to that receiver, then it needs
to ask the receiver for their mailbox fullness before each message?  I think
this seems like a reasonable thing for threads, but for processes talking
across a network, you ideally want to be able to send a dozen messages as
fast as you can while listening for some kind of a congestion marker coming
back to you, rather than inserting an "okay to send? (wait for reply)" loop
before each message.

In other words, I think networks scale better if you can find a way to make
this a soft or "best-effort" limit.  Maybe the 'ack' for each message
contains the fullness of the mailbox, and senders don't block until they
know it's full, which might mean a few extra messages get packed into the
box before everyone gets the word.

The other aspect is that the sender needs to keep track of the limits (in
the network scenario) since they will need to tell senders to retry (or will
all the senders just poll once a second?).

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100120/fe569c8d/attachment.htm>