Yeah, I'm not sure it is necessary either, but I was mostly curious to see what it would take to get it to work and if it might help ward off the spurious lag monster. The jury is out on both, but if you want to take a look at the approach, I created a fork here:
github.com/mnocu/tbamud
which should work (dubiously) in Linux. I'll also look for a spot to attach the 5 files I modified somewhere here.
The basic idea was to launch a facsimile of the game loop in another thread that handles heartbeat functions and leave the I/O in the original thread. So, the bulk of the changes are in comm.c with a few additions to comm.h, structs.h, and the function/macros to handle the mutex locks in utils.c and utils.h. That's really all I've done to get a working multithreaded copy of tbamud.
Mutex locks are missing in a lot of places -- I didn't do a full analaysis of where they will be required, but there are a lot of places where they are still needed to guard the descriptors. Ideally, the descriptor is the where the threads intersect... In thread 1, the game_loop() should handle the low-level descriptor functions (and perhaps anything that might need to happen in the background) while thread 2 runs the bulk of the game mechanics (which inherently will need to access the descriptors at times). An analogy would be thread one is the joystick, keyboard, and monitor I/O and thread two is all the underlying mechanics of the game.
If nothing else, it's an interesting experiment in dualing threads and maybe a starting point (or example of what not to do) for anyone else thinking about recruiting additional cores to their cause.
