Message-Passing

[Manu]

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! :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120120/dc338183/attachment.html>