Closed cbarton closed 6 years ago
Thank you.
There is one thing I'd like to point out. Every Hutch broker also uses at least one channel. Channels are not supposed to be shared between threads for many operations, in particular publishing. This PR does not address that, so application developers need to bring their own synchronization at least for Hutch.publish
.
@michaelklishin I agree that the Hutch.publish
calls should be synchronized since the callers might be sharing a channel across threads. I was going to open up a PR for that case after seeing feedback from this PR. Would you be open to that or would you rather leave the publish synchronization up to the application devs?
Synchronization introduced a 10-11% throughput drop (measured a few years ago when the same thing was considered Bunny), less so with Monitor than Mutex.
I'm not sure how many people actually publish concurrently with Hutch, although some may end up doing so without knowing it.
Ya, I figured the performance overhead would be something to consider in the library making this the default behavior. I'll stand down on the other PR.
Have a good one!
When there are competing publisher threads, there is a chance that the publisher has not been initialized when Hutch is registered as connected. This happens when connections are lazily created vs at application load (for example). The following diagram should shed some light on the race condition:
Wrapping the
Hutch.connect
call should resolve this issue.