Event queue synchronization prevents concurrency #172
Description
If Pusher isn't designed for multi-threading, then please ignore me. However, from the documentation and after a bit of playing around with the code it looks like it should be possible -- although I've seen more than a few hints to not use multiple Pusher instances.
What is the issue?
To resolve #54 and #98 synchronization on the event queue was added (see #102).
The original problem needed to be solved was to enforce determinism in the connection logic. However, the implemented solution affects handling of all types of events.
In my case I'd like to bind different SubscriptionEventListeners to different types of events and process the different events concurrently.
In the simplest case I'd like have two Pusher instances subscribing to two different Channels. Upon connect() they each create their own socket and start decoding incoming events and passing to the event queue each with their own thread. So far everything looks good.
However, since there's a static (global) synchronization on the event queue, there's constant locking on the two event queue threads before they can pass the messages onto the listeners. I.e. the fact that I'm using two Pusher instances actually lowers performance compared to having a single Pusher.
Any improvements you suggest
I'm not sure if it could be as simple as separating out the connection mechanism (session layer) from the rest of the message processing (business layer).
I'd be happy to try and help on this, but I believe I'd might need a bit more background on any potential known limitations in relation to threading design for Pusher for that.
Thanks for making a very useful lib!
CC @pusher/mobile