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.
