On 20 January 2012 00:36, Sean Kelly <sean@invisibleduck.org> wrote:
Thanks :-)  If you have ideas on how it could be improved, please let me know.

On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:

> I want to applaud Sean Kelly and everyone who worked on std.concurrency for a great API, and wish that I could easily write Cocoa applications with it.
>
> I'm writing a screen recording program in Objective-C, and to make sure each frame has an equal length, I have two threads: one that takes the screenshot at certain intervals, the other that assembles it into a quicktime movie. After writing an implementation of a thread-safe queue, where the picture-taking thread adds and the assembling thread removes, I realized the huge similarity between what I'd done and std.concurrency.
>
> The std.concurrency module would have made hours of effort in ObjC take five minutes in D. Well done!

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.

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.
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 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 the problem here is that I'm not SHARING values between threads, I'm actually passing ownership of something to another thread. So I wonder if some improvement can be made in this area.

I was going to complain about the documentation, but I just checked, and it seems to have had work since I was reading it. Looks much better now! :)