[MUD-Dev] Re: Yet another update on threads and signals

[Chris Gray]

[Adam J. Thornton:]

 >OK, so trapping the signal in a signal handler won't work, because the
 >POSIX thread functions are not reentrant.
 >
 >However, using sigwait() will, so instead of a signal handler, I'll spawn a
 >thread whose only purpose in like is to wait for that signal and, upon
 >receiving it, do its magic.  It can just block in sigwait() until the
 >signal is delivered.

I was going to reply to this thread yesterday, but was checking to see
if anyone else had good ideas, and then forgot...

It would add a bit of extra latency, but consider having an extra
process to act as an fd distributor. Each room-process would have an
open socket to that process (the distributor avoids each room having
to have a socket to every other room). Then, to send a player from
one room to another:

Departing room:
    write a message, with room indicator and fd, to the distributor

Distributor:
    sitting on select on the set of room sockets.
    wakes up, reads message and gets fd.
    writes message on socket to target room

Target room:
    sitting on select of player sockets and distributor socket
    wakes up, sees activity on distributor socket
    reads message and gets fd - player is moved.

Presumably you could send whatever other data you wanted along with
the fd, perhaps minimizing the amount of shared memory or file I/O
that is needed to move the player. Normally, using the sockets is
more expensive than, say, shared memory, but since you would already
be using it, there is little extra cost in sending more data.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA