[std.concurrency] prioritySend is 1000 times slower than send?

[osa]

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.