You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #56 and #119 there will be much bigger need for one producer per thread.
This cannot be done in an efficient way if we create a thread per instance hence this proposal.
In order to make sure we do not change the behaviour for multi-threaded single producer and we ensure the consistent experience of deliveries as we do now the proposition is as follows:
Create a single thread for all producers
Look into fiber scheduler to be able to wake up in an async manner OR investigate some sort of improvements over current polling mechanism and the CPU usage of a 1ms polling (dunno yet)
The current threading model is def. not sufficient for multi-threaded operations and due to the producer "self managing" polling it seems this needs to be done at this layer
The text was updated successfully, but these errors were encountered:
With #56 and #119 there will be much bigger need for one producer per thread.
This cannot be done in an efficient way if we create a thread per instance hence this proposal.
In order to make sure we do not change the behaviour for multi-threaded single producer and we ensure the consistent experience of deliveries as we do now the proposition is as follows:
The current threading model is def. not sufficient for multi-threaded operations and due to the producer "self managing" polling it seems this needs to be done at this layer
The text was updated successfully, but these errors were encountered: