On 20 January 2012 00:36, Sean Kelly <[email protected]> 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! :)
