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

[Sean Kelly]

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 think this is really more of just a tuning issue.  And in fact, that the PriorityMessage exception is a template isn't feasible for out-of-process messaging, so this is an issue that has to be addressed at some point anyway.  I think I'm going to both change the exception to be generated within receive() only if needed, have it contain a variant instead of a templated type, and possibly also not generate a stack trace for it.  I haven't decided whether a trace is meaningful in this context.  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'm looking into the hang issue as well... it's just less obvious where the problem is there.