[dmd-concurrency] draft 5

[Kevin Bealer]

On Wed, Jan 20, 2010 at 1:21 AM, Kevin Bealer <kevinbealer at gmail.com> wrote:

> 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?).
>

Sorry, here I meant that the receiver needs to keep track of the senders'
(plural) limits.


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