Message-Passing

[Manu]

On 20 January 2012 20:06, Sean Kelly <sean at invisibleduck.org> wrote:

> On Jan 20, 2012, at 5:10 AM, Manu wrote:
> >
> > 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.
>
> Erlang has functions to link and unlink threads from one another, and I've
> already implemented a bit of it in std.concurrency.  A fuller
> implementation would probably be sufficient for your needs.
>
>
> > 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.
>
> Matter of opinion.  I think receiveOnly indicates what the function does,
> and I think it's important to indicate that receiving anything else is
> unexpected and will trigger an error.
>

Well I'm just saying as a new comer what I consider to be intuitive or not
with respect to what I've used in other languages (in my case, C/C++, C#,
java, php, ecma, etc)... I've never seen an api like receive() in any
language before. It definitely is a D-ish API, and wouldn't be expected by
most users.
I also think most instances of passing messages between 2 threads will have
a tight well-defined expectation of send/receive types. receiveOnly() seems
far more intuitive to me, and simpler to achieve 90(100?)% of my jobs.
Eg, I press '.' and the list of methods appears, and I skim through the
list and choose the one that looks appropriate, I'll choose receive, and
then I'll be puzzled by the argument list and why it doesn't work like I
expect, after a little wasted time, I may begrudgingly read the manual... I
personally feel this is an API failure, and the single most important thing
that C# gets right. You can literally code C# effectively with absolutely
no prior knowledge of the language just using the '.' key with
code-complete in your IDE. The API's are really exceptionally intuitive.



> > 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 think this is an artifact of the syntax.  There's no way to have a
> return value that indicates a timeout occurred.  If receiving a duration
> (ie. a non-reference type) doesn't work then I'd consider that a bug.
>

Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very
important function for my money. I think many usages will not want to block
indefinitely.

Actually, on that note, I really wanted a poll() function. I never want to
block for messages, just grab one if there is one waiting in the queue.
receiveTimeout(0) seems to be the only way to do it... Again, not
particularly nice or intuitive.
Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I
think they're all good to have.


> 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 Unique!T should work for the sending side, and then the receive
> side wouldn't have to receive shared(T).  It's something that's been on the
> radar, but I haven't done anything about it yet.


Cool, I'll be interested to see what nice solutions for this could exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120121/cc4c2916/attachment.html>