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.
