std.concurrency extension

jdrewsen jdrewsen at nospam.com
Wed Jun 8 12:59:14 PDT 2011


Den 08-06-2011 16:47, Sean Kelly skrev:
> On Jun 7, 2011, at 3:07 PM, jdrewsen wrote:
>
>> Hi,
>>
>>    Currently each thread spawned has an associated Tid when using std.concurrency. When calling receive() this is always the Tid (and associated messagebox) that you receive from.
>>
>> This becomes a problem when you spawn several worker threads that send messages to the main thread since each call to receive must know how to handle all kind on messages.
>>
>> For example: the current version of the curl wrapper I'm working on receives HTTP data from worker threads using receive. The user of this wrapper can also create his own worker threads that will send data to the main thread. This means that the curl wrapper must be able to handle the users worker thread messages.
>>
>> The GO language has solved this problem with channels. My suggestion is to allow a thread to create additional Tids that can act just like channels. Then by adding a receive() call that accepts a Tid as first argument we can use them as channels.
>
> A Tid is a thread ID, thus "tid".  The current design allows you to design any message format you want.  In Erlang (on which this design is based), it's common practice to have the sender's Tid included in the message.  As for channels... I hope that they can be built on top of the existing messaging system.  They might not be as optimal as a from-scratch approach though, since a bit of extra dispatching would need to be done in the wrapper.

I took a look at the std.concurrency code and noticed that one of my 
assumptions was wrong: A receive call does not necessarily handle 
messages in the messagebox in the order they arrive. If a message cannot 
be handled by the receive call then the next message available in the 
messagebox is tried and so on. My assumption was that it would throw.

Now that I've checked in TDPL I can see that it is actually documented 
there. The library API documentation on the web could use some fleshing 
out though.

Sorry about the noise.

/Jonas


More information about the Digitalmars-d mailing list