Message-Passing

[Sean Kelly]

On Jan 20, 2012, at 5:10 AM, Manu wrote:
> 
> I had some troubles with std.concurrency which I thought it might be nice to address.
> 
> Perhaps the most major problem I had was related to the concept of thread ownership. If a spawned threads parent thread dies, it also receives a signal to kill its self, but it seems impossible to reassign ownership.
> In my case I had threads A, B and C...
>   Thread A is the main thread, which may spawn many temporary worker threads B, which may last 1-2 seconds.
>   During the life of B, it may spawn C, which may persist for hours.
>   B promptly dies, and any C's that were spawned receive the kill signal, which I ignore.
>   Thread A, the main thread may exit, and I would really like all C's to receive that notification, but they were are all orphaned when their B died.
> The problem is, when I spawn a C, it should be created as a child of A somehow, rather than a child of the transient B... Some mechanism to solve this sort of problem would be useful.

Erlang has functions to link and unlink threads from one another, and I've already implemented a bit of it in std.concurrency.  A fuller implementation would probably be sufficient for your needs.


> Another usability problem I had was that, intuitively, the simpler function with intuitive usage pattern receiveOnly() should be named receive().
> And receive() with the complex var-arg list of delegates should be named something more complex.

Matter of opinion.  I think receiveOnly indicates what the function does, and I think it's important to indicate that receiving anything else is unexpected and will trigger an error.


> receiveTimeout() has no receiveTimeoutOnly(), which is the function I almost always want to use... and receiveTimeout() didn't actually work for me anyway (it wouldn't receive a duration as per the documentation, I had to pass an int)

I think this is an artifact of the syntax.  There's no way to have a return value that indicates a timeout occurred.  If receiving a duration (ie. a non-reference type) doesn't work then I'd consider that a bug.


> I wonder if there is a solution to the 'shared' problem. Basically every single line of code that uses the std.concurrenty api is riddled with casts to/from shared... really ugly.

I think Unique!T should work for the sending side, and then the receive side wouldn't have to receive shared(T).  It's something that's been on the radar, but I haven't done anything about it yet.