[ENet-discuss] Enet and multithreading

[Lee Salzman]

You would need a mutex guarding access to the queues packet.

To this and other issues all I can say is:
ENet is a small library, meant to be ripped up and molded
to whatever need you have. So just modify it in whatever way
you see fit, and ENet is extremely unlikely to change at all
in the future in ways that would mess with your modifications.

Lee

David Anderson wrote:

> Hello,
>
> I have recently discovered Enet and am planning to use it in a game 
> engine instead of our current socket management layer. However, the 
> engine is multithreaded, which brings up some questions relating to Enet.
>
> I see in the archives that multithreading is somewhat a recurring 
> topic, but I didn't find anyone with the exact kind of problem I think 
> I may run into.
>
> The network layer of the engine runs in its own thread for receiving 
> data/new connections, and queues received packets in a Glib 
> asynchronous queue (the glib way of communicating data between 
> threads). Sending is done by another thread which calls a send 
> function in the network module.
>
> That is my first concern: with one thread looping on enet_host_service 
> to manage incoming data, is it safe to call enet_peer_send or 
> enet_host_broadcast from another thread? My instinct tells me that if 
> there is no thread-safety within the lib this would be an extremely 
> bad idea, but perhaps its structure would make this safe somehow?
>
> My other concern is that I need to be able to notify the receiving 
> thread that it should shut down. The only way I can see right now it 
> to have enet_host_service timeout after some time, and check a boolean 
> flag each time it times out and/or services events. My problem with 
> that is that it'd be more efficient to have enet_host_service running 
> with no timeout, and being able to 'signal' enet in some way to make 
> enet_host_service return prematurely (with no event) only when I 
> actually want to shut it down. Is this somehow possible?
>
> Thanks in advance for any input on these questions,
> David Anderson