Concurrency

[Graham St Jack]

On 26/07/10 13:48, Sean Kelly wrote:
> Graham St Jack Wrote:
>
>    
>> However, I have had some problems with std.concurrency (most of which
>> I'm sure are already being addressed by Sean). In particular, I wanted a
>> way to select on multiple file-descriptors so that I could (say) send
>> commands to a thread that also reads from a blocking file-descriptor
>> like a serial port, UDP socket or GTK main loop.
>>      
> Hm... this is essentially what libev and libevent do.  The trick is mostly making this work in a consistent and performant manner on both Posix and Windows.  On Posix, the read event simply tells you data is available, while on Windows the read event hands the data to you directly.  The former works quite well with messaging while the latter... well, it's kind of weird.
>    
I don't know much about Windows programming, but I was expecting this to 
be the sticking point. So do we have a solution in D for this? For me, 
it is the key issue with std.concurrency as it stands.

Using the Pipe approach as I did in Channel, maybe a Windows version 
could allow a byte to be removed from the Pipe for each message, and 
another byte immediately put on to replace it if the Channel was not 
then empty.
> I like that you're playing with Channels, by the way.  I chose the messaging API in std.concurrency because it can have a range of more structured models built on top of it, so I think it's more likely to see broad use done this way.  Maybe channels will be the first :-)
>    
The Channels I proposed were really just a first try at doing code 
generation, but they do work really well. I particularly like being able 
to print out the generated code to see what you are getting. I must 
admit that I find Variant perplexing, and had issues with the message 
size limitation and no prohibition on aliased message parameters.

In working with both std.concurrency and alt.concurrency, I have found 
that alt.concurrency has some advantages such as:

Creating Channels first and providing them as arguments to spawn() is 
simpler than spawning threads and passing Tids in messages.

Being able to use the same set of parameter types in two different 
messages, and having names for the messages is clearer.

Being able to have multiple threads reading messages from the same 
Channel - something I need (well, want because it is much easier than 
double-handling all the messages through an intermediary) on my current 
project.

The benefit of compile-time checking.


Of course std.concurrency has lots of bonuses too. What I am after is a 
discussion that leads to a std.concurrency that is better still.


By the way, how are you getting on with rolling out "shared" through 
core.sync? I'm very keen to find out if shared can at last be used as 
intended - such as for implementing a Channel. I could lend a hand if 
you need one.

-- 
Graham St Jack