Question Intermud Grapevine Chat support

Hello folks,

I've completed basic integration with my Circle/TBA-based MUD with Grapevine to allow for gossip and tells to be sent between different games. Info about Grapevine itself can be found at grapevine.haus/

This is a modern and secure alternative to older intermud systems like i3 that uses TLS and web sockets. My implementation does require you compile in C++. Details available here: github.com/halimcme/worldofpain

Thanks,

-Blizzard

Thanks for this, but seems to be lacking in thread safety I think? The on message callback runs in another thread and the message handler functions are touching your main thread resources (descriptor_list, character_list). Are you seeing issues from this? I'm seeing intermittent segmentation faults.

I haven't had any issues like that related to threading. I haven't really done any coding with threads before. Would it make a difference that my descriptor_list and character_list are C++ lists of pointers?

Maybe I'll have to look at rewriting it with a web socket library that doesn't use threads. This one just looked easiest to write code for, after checking out several.

or maybe I can implement locking around the part of the game loop where these data structures may be modified. I'll read up on that.

I added
// lock threads for the main loop
std::mutex mtx;
mtx.lock();

and
// unlock the thread
mtx.unlock();

at the beginning and end of the game loop and it appears to work still. I'll let it run under gdb for a bit.

Turns out the segfaults were an unrelated issue, but yes, I think you'll need to add some locking for thread safety. For instance, say a broadcast message comes in on the websocket thread. You handle it in GvChat::eventBroadcast, doing send_to_char to everybody, but what if your main thread is also doing a send_to_char to the same player at the same time? 2 threads writing to the same memory at the same time is no bueno .
Easiest way to handle it I think is to put the incoming messages in a queue that you periodically come and handle from the main thread. I thought you might have had that in mind since you added _receivedQueue (though unused). You use a mutex to lock access to the queue. When new message comes in, lock the mutex and add it to the queue. Somewhere in your main thread (game_loop) you call into a function that locks the mutex and processes all the queued messages. Anyway, that's the general idea and seems to work for me. However, this introduces a new wrinkle, which is that (at least in our game) the main thread sleeps when nobody is logged in, so after a while of not answering the heartbeat events, grapevine connection will drop. Probably makes most sense to close connection from our end before we go into the "no player" sleep, and reconnect once somebody logs in.

Just to note, there are some other bugs in there as well. For instance, doing gvtell with no arg crashes.