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