Kevin Bealer wrote:
> I like the free form better.  Once you start using foo.method(...) you are implying that foo is the one stop shop for message passing behavior (or at least an important part of a balanced breakfast).

I agree.

Andrei

Steve Schveighoffer wrote:
> receive is short for thisTid.receive.

If I need to write thisTid.receive, then presumably I could be able to receive on behalf of any other thread by writing thatTid.receive. That isn't the case.


Andrei

Yah, it was mentioned and fixed. Thanks.

Andrei

Kevin Bealer wrote:
> In this line from 'main()', I think 'message' here is a cut n' paste stowaway?
> 
> writeln("Main thread: ", message, i);
> 
> Kevin
> 
> On Tue, Jan 12, 2010 at 3:45 AM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
> 
>     To be found at the usual location:
> 
>     http://erdani.com/d/fragment.preview.pdf
> 
>     I didn't add a lot of text this time around but I do have a full
>     example of communicating threads. Skip to the last section for
>     explanation. I paste the code below. I think it looks pretty darn
>     cool. Sean, please let me know if it floats your boat.
> 
>     import std.concurrency, std.stdio;
> 
>     void main() {
>       auto low = 0, high = 1000;
>       auto tid = spawn(&fun);
>       foreach (i; low .. high) {
>          writeln("Main thread: ", message, i);
>          tid.send(thisTid, i);
>          enforce(receiveOnly!Tid() == tid);
>       }
>       // Signal the other thread
>       tid.send(Tid(), 0);
>     }
> 
>     void fun() {
>       for (;;) {
>          auto msg = receiveOnly!(Tid, int)();
>          if (!msg[0]) return;
>          writeln("Secondary thread: ", msg[1]);
>          msg[0].send(thisTid);
>       }
>     }
> 
> 
>     Andrei
>     _______________________________________________
>     dmd-concurrency mailing list
>     dmd-concurrency at puremagic.com <mailto:dmd-concurrency at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

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

I see you covered my question about if the read/write file thing would actually speed things up! I think the explanation reads well, and segues well into the read file / write to network crowding problem.

Andrei Alexandrescu 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
>
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
>

Le 2010-01-19 ? 5:30, Andrei Alexandrescu a ?crit :

> I uploaded draft 5 here:
> 
> www.erdani.com/d/fragment.preview.pdf

Extracts from it:

> As discussed, passing data around is possible because of immutable; if you replaced immutable(ubyte)[] with ubyte[], the call to send would not compile.


That's nice and appropriate for inter-thread communications.

But won't it be a little wasteful when we come to inter-process or network communications, when you need to make a serialized copy of the message? If you force the user to make an immutable copy, and then create a new copy via serialization, the immutable copy is wasted, no?

I ask now because this is a pretty fundamental thing (passing a message) and you said at the start of this mailing list that the intent was for the message API to scale well to all these cases.


> enum OnCrowding { block, throwException, ignore }

What's going to be the standard for naming things in Phobos? Walter's guideline says enum members and constants should be ALL_CAPS, but looking at your code Andrei, here and elsewhere in Phobos, it doesn't seem like you like this rule.

Also, "throwException"... wouldn't it be better if it was named so to tell us which kind of exception is thrown? Like "throwTooCrowded" or something. Which makes me think that I don't see anywhere in your text which kind of exception is supposed to be thrown.

Last is an idea to improve the API, but probably won't have any consequence on the book unless you want to talk about it. In addition to the function taking standard enumerated values I think having this would be great:

	alias void delegate(Variant message) shared OnCrowdingHandler;
	void setMaxMailboxSize(Tid tid, size_t messages, OnCrowdingHandler doThis);

With this I could setup things so that if one thread is crowded the message would be sent to another thread instead. I could also want to write a log of those unpassed messages or something. Or I could make a zero-sized mailbox and use the crowding callback to send the message using an alternate dispatching mechanism (like sending a GUI event, making the GUI tread able to receive messages).

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On Tue, 19 Jan 2010 08:02:25 -0500, Michel Fortin <michel.fortin at michelf.com> wrote:
> Last is an idea to improve the API, but probably won't have any consequence on the book unless you want to talk about it. In addition to the function taking standard enumerated values I think having this would be great:
>
> 	alias void delegate(Variant message) shared OnCrowdingHandler;
> 	void setMaxMailboxSize(Tid tid, size_t messages, OnCrowdingHandler
> doThis);
>
> With this I could setup things so that if one thread is crowded the message would be sent to another thread instead. I could also want to write a log of those unpassed messages or something. Or I could make a zero-sized mailbox and use the crowding callback to send the message using an alternate dispatching mechanism (like sending a GUI event, making the GUI tread able to receive messages).
>

Currently, alias void delegate(Variant message) shared OnCrowdingHandler; doesn't compile, though I definitely see the usefulness of shared delegates. Should this be filed in bugzilla?

I think it should compile, so you may want to add it to bugzilla.

Andrei

Robert Jacques wrote:
> On Tue, 19 Jan 2010 08:02:25 -0500, Michel Fortin <michel.fortin at michelf.com> wrote:
>> Last is an idea to improve the API, but probably won't have any consequence on the book unless you want to talk about it. In addition to the function taking standard enumerated values I think having this would be great:
>>
>>     alias void delegate(Variant message) shared OnCrowdingHandler;
>>     void setMaxMailboxSize(Tid tid, size_t messages, OnCrowdingHandler
>> doThis);
>>
>> With this I could setup things so that if one thread is crowded the message would be sent to another thread instead. I could also want to write a log of those unpassed messages or something. Or I could make a zero-sized mailbox and use the crowding callback to send the message using an alternate dispatching mechanism (like sending a GUI event, making the GUI tread able to receive messages).
>>
> 
> Currently, alias void delegate(Variant message) shared
> OnCrowdingHandler; doesn't compile, though I definitely see the
> usefulness of shared delegates. Should this be filed in bugzilla?
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

Steve Schveighoffer wrote:
> On page 15 of the chapter: "Read data from the source file in a buffer with error checking" change 'in' to 'into'
> 
> Same on page 16: "Read data from the source file in a newly-allocated buffer with error checking"

Thanks!

> The bit about doing the setMailboxSize right after calling spawn is a little disconcerting to me, do you think it might be possible spawn a thread in suspended mode (i.e. don't start it right away)?  I think there are probably other reasons you may want to configure the tid or set up some kind of framework before letting the thread start for a more controlled startup procedure.

Yah, there will most likely be a way to start a thread suspended. In this case it's not crucial because you should be able to set its mailbox size while running.


Andrei