On Thu, Dec 8, 2011 at 5:53 PM, Sean Kelly <[email protected]> wrote: > On Dec 8, 2011, at 8:23 AM, Manu wrote: >> >> Just digging through concurrence.d since the docs are pretty bare, and I've >> come across this pattern, which raises a pretty worrying alarm to me. I >> wonder if this is common in D libraries... >> >> ... >> >> No overload, receives a tuple, and assumes that static-if the first tuple >> item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the >> 'overload'... >> >> I guess this means I can never pass a Duration in a message to the >> non-timeout receive()... or anything that is implicitly convertible to a >> Duration. > > Right. The only thing you can pass to receive() are functions taking one or > more parameters. mbox.get() itself is actually pretty lax in enforcing this > because it relies on the caller to do most of the filtering (via checkops). > This should be safe since the mbox itself is private. I suppose I could have > done this a different way, but overloading when one function has (T…) args is > a bit weird. > > >> This would seem to be a very obscure hidden bug to me. Is this a common >> pattern in D? > > It's probably the only case. > > >> I certainly wouldn't want to be tracking down this bug on build night... Is >> there something I've missed here? Some sort of safeguard I've overlooked? > > See above. MessageBox is private and receive() does the parameter checking.
This is somewhat of a threadjack, but I was looking at making a lighter actor-like abstraction for message passing, and possibly making it compatible with std.concurrency, and I saw this: "The general idea is that every messageable entity is represented by a common handle type (called a Cid in this implementation), which allows messages to be sent to in-process threads, on-host processes, and foreign-host processes using the same interface." As far as I can tell, Cid does not appear outside the documentation at the top of std.concurrency, and Tid is a direct linkage to std.concurrency's private mailbox implementation, so I was wondering what the best way to extend message-passing functionality to another type would be.
