[Shooting King]

If the /test is executed multiple times(i.e before completion of file download), Multiple threads will be created overriding g_iThreadHandle with the same call backs, causing improper execution of callback functions with different handles, will not work as you have expected, ofcourse its not the way the API is intended to be used.

In this Module's Threading model, there are no bottlenecks, so no race conditions/locking. One unique handle per thread, One socket per thread.

Your possible models (to be used in your plugin),
Sequential Model -> Create a thread, sendData of player1, In the callback, sendData of player2, again in callback send data of player3,....
Or
Concurrent/Parallel Model -> Create 32 Threads (if you have enough system resources), Send data of one PLayer1 from Thread1, PLayer2 on Thread2, and so on...., but don't expect the order to be same on the other endpoint, like player2 Data may be received first or player3-player1-player2 or some other combination.

In Either case, There will be no race/locking in the Module.