Closed mwhicks-dev closed 5 months ago
Checked: No duplicate assets are being created by Client
Checked: No asset duplication in server
Checked: Client IDs are behaving as intended
Found: Similar issue happens with just 1 client creating a character...
Found: When running in a single thread via Valgrind, no issue. This is likely a race condition
My guess is that since updates are being ran on the client-side character and the networked character at the same time, this is blowing up one of the client-side event handlers somehow.
Maybe awaits?
Locking OrderedPriorityListener::await
solved the problem with both just one of them, but did not solve the problem for both of them running... so that is a dead end for now
I think this is happening because of how Response ClientController::await(Request)
is implemented -- I don't really understand how 0MQ structs work, but from what I have read, zmq::context_t
is thread-safe but zmq::socket_t
is not. This is causing some problems since the method is not synchronized!
In both controllers, I think I would like to create a single zmq::context_t
and scope zmq::socket_t
s to have the shortest lifetime possible so that -- only created in the absolutely necessary point in the loop -- each locked behind their own mutex. (As much as I don't like having several mutexes...)
I tried to add the above, but this made things choppy. For now, I am just going to try and improve my controller ZMQ flows without worrying about synchronization.
For now, I will try and resolve the first weird join issue and see if that helps.
At least as of 20253faf5122eb2abb8b0d65d6371b3f2ddaa5a3, whole thing blows up when two clients join. This didn't happen earlier so I'm not sure what is up.