SmartFox.Send() locks thread it's called from if it's already processing other packet
Posted: 31 Oct 2024, 15:45
Hi there, I don't know whether to call this a bug-report or a feature-request, so I apologize for any formatting issues.
Ran into an issue with our Unity project recently where we're sending a larger packet, however any subsequent requests/packets we try to send while that larger packet is being processed lock up the thread they're sent from (in our case that's the Unity main thread) which is fairly problematic. This thread is completely locked until the larger packet finishes processing and is sent off.
We tracked the issue to a ThreadManager class, where the OutThread processes each request/packet from a queue on its own thread. While the OutThread is processing, it sets a lock. The issue is that the method EnqueueSend() from that same class uses the same lock, so our main thread stops while it waits for that lock to open up.
I can see how this is fine in majority of cases, since the thread sleeps for a couple of ms to allow for requests to queue up, but we have a couple of instances where we're creating larger requests or many smaller ones where we're running into this.
We can avoid having the main thread lock up by spinning up a new thread and calling SmartFox.Send() from that thread, but it doesn't solve the issue that no requests/packets are being handled while processing the larger packet. We have objects that are trying to send out data every update, but they can't because of the larger packet which takes anywhere from 0.1-10 sec to process (likely due to compressing it).
Ideally, it would be nice to have each request/packet processed on its own thread, since right now they're all queued up into the same thread. That way we can process a larger packet alongside all the smaller ones without delaying any packets or locking our main thread. Or at least be able to process a separate larger request/packet independently.
Cheers
Ran into an issue with our Unity project recently where we're sending a larger packet, however any subsequent requests/packets we try to send while that larger packet is being processed lock up the thread they're sent from (in our case that's the Unity main thread) which is fairly problematic. This thread is completely locked until the larger packet finishes processing and is sent off.
We tracked the issue to a ThreadManager class, where the OutThread processes each request/packet from a queue on its own thread. While the OutThread is processing, it sets a lock. The issue is that the method EnqueueSend() from that same class uses the same lock, so our main thread stops while it waits for that lock to open up.
I can see how this is fine in majority of cases, since the thread sleeps for a couple of ms to allow for requests to queue up, but we have a couple of instances where we're creating larger requests or many smaller ones where we're running into this.
We can avoid having the main thread lock up by spinning up a new thread and calling SmartFox.Send() from that thread, but it doesn't solve the issue that no requests/packets are being handled while processing the larger packet. We have objects that are trying to send out data every update, but they can't because of the larger packet which takes anywhere from 0.1-10 sec to process (likely due to compressing it).
Ideally, it would be nice to have each request/packet processed on its own thread, since right now they're all queued up into the same thread. That way we can process a larger packet alongside all the smaller ones without delaying any packets or locking our main thread. Or at least be able to process a separate larger request/packet independently.
Cheers