On 09/30/2010 03:33 PM, Sean Kelly wrote:
osa Wrote:
I've also thought about switching to 'send' if the receiver queue is
empty, but there is no way in std.concurrency API to check for that. Is
there any serious issue with adding such method? I understand that in
multi-threaded environment an empty queue as told by 'isEmpty' call may
become non-empty before that fact is used, but in some situations
approximate result (means empty or almost empty) is fine.
The current API is designed to apply to in-process and out-of-process
messaging, so a function like that doesn't really fit.
I see. It is reasonable if out-of-process messaging is going to be
implemented.
Getting a PriorityMessage exception could imply a failure to receive() a type
required by the application design so a trace might be a good indication of
where the error is... or maybe that's just wrong.
I'd say that having a trace for exceptions thrown by recieve may be
useful only if you have many receieve() calls scattered all over the
code, with try...catch on the very top level. But my (limited)
experience with std.concurrency way of thread communication tells me
that it is a bad idea; I'd use as few calls to receive() as possible and
keep them close to each other. But people's mileage may vary.
