Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to build a multi-threaded mwe #253

Open
cuppajoeman opened this issue May 12, 2024 · 0 comments
Open

Trying to build a multi-threaded mwe #253

cuppajoeman opened this issue May 12, 2024 · 0 comments

Comments

@cuppajoeman
Copy link
Contributor

cuppajoeman commented May 12, 2024

Hi there,

I've been trying to build a client-server architecture with enet, I've been running into some problems. I'm aware that enet doesn't have multi-threaded support, and I want to build a small example that allows for usage of enet from a multi-threaded point of view, so far I have this code:

https://github.com/cuppajoeman/mt_cs_enet

This is an example of multi-threaded usage of enet, WITHOUT any locking mechanisms. For example, when I run the server and two clients usually one of them segfaults (not immediately), with:

enet_list_remove (position=0x7ffff0001210) at /home/ccn/temp/enet_multithreaded/server/external_libraries/enet/list.c:37
37         position -> previous -> next = position -> next;

I don't really know what causes this problem, but I'm assuming it's the multi-threaded access of enet.


Would someone be willing to take a look at the code I linked to and propose a way to add mutex's to make it thread safe? I'm not quite sure how to approach it.

The files of interest are going to be:

The structure of the client is that there is a send and receive thread, the sending thread simply creates a struct, puts it into a packet and then sends it with enet_host_flush(...) and the receive thread calls enet_host_service(...) over and over.

The structure of the server is pretty much the same, along with a process thread which sits between the receive and send, when InputSnapshot's come in from the client, they get put on a thread-safe queue, which is then intermittently drained from the process thread, which increments a global num_inputs_snapshots_processed counter, the send thread simply sends this number back to the client.

The general structure tries to mimic that of a multiplayer game, but in the smallest possible way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant