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
Currently RakLib uses two global channels for inter-thread communication (one for each direction).
These global channels are a major bottleneck for RakLib scaling because every packet sent or received from any session passes through these channels. This has two effects:
Frequent lock contention: it's likely that contention for mutex locking will occur when pushing stuff into channels while the other thread is trying to pull it out.
Inability to use multiple CPU cores: these central channels are a big showstopper for parallel scaling, because inevitably worker threads would end up contending for locks on the channels with other worker threads.
This issue proposes that each RakLib session should have its own ITC channel pair. This may be tricky to implement due to pthreads stupidity, but in terms of code complexity it's simple and effective.
The text was updated successfully, but these errors were encountered:
this is a working implementation of #52.
I have my doubts that this gigantic refactor was worth the effort, because there's still lock contention on Snooze to consider; however, this does substantially reduce the problem described in pmmp/ext-pmmpthread#42, as well as reducing the overhead of inter-thread communication by removing the need to transmit session IDs.
This currently relies on each end of the IPC channels to roundtrip session open/close notifications to setup/cleanup stuff; I'll try to improve this before landing this in main.
Currently RakLib uses two global channels for inter-thread communication (one for each direction).
These global channels are a major bottleneck for RakLib scaling because every packet sent or received from any session passes through these channels. This has two effects:
This issue proposes that each RakLib session should have its own ITC channel pair. This may be tricky to implement due to pthreads stupidity, but in terms of code complexity it's simple and effective.
The text was updated successfully, but these errors were encountered: