Message-Passing

[jdrewsen]

On Friday, 20 January 2012 at 13:10:37 UTC, Manu wrote:
> On 20 January 2012 00:36, Sean Kelly <sean at 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! :)

It still needs to document that the ops in "void receive(T...)(T 
ops)" can return false if they did not handle the message. This 
is useful when you want to receive a message from a specific 
spawned subthread (tid).

/Jonas