[MUD-Dev] Passing file descriptors to other processes

[Adam J. Thornton]

Hmmm.

I've hit another roadblock.

In my design, you may remember, if a player connects to the server daemon
and wants to be in a room where there are already connected players, then
that room has a process associated with it.

So I can pass the file descriptor of the open socket to that process with
sendmsg, and receive it with recvmsg...

But, with sendmsg and recvmsg, I can't target a specific process, so any
process that's listening might grab the connection--this is wrong, I want
it to go to a specific room process.

So here's my solution; it seems ugly to me and I was wondering if anyone
sees an obviously better way to do it.

Server Process                          Room Process
--------------                          ------------
mutex_lock 
  signal to room process
                                      signal received
                                        signal handler
                                         block all new signals
  sendmsg (blocking)=fd                  recvmsg (blocking)
**************Processes Synchronized Here********************
                                         get fd out of message
                                         spawn player thread connected 
                                          to new fd. 
  recvmsg (blocking)			 sendmsg(blocking) = "done"
**************Processes Synchronized Here********************
                                         unblock signals
mutex_unlock                            exit signal handler


The reason for the mutex is so that there's only ever one attempt to pass a
file descriptor at a time.  The signal() will alert the room process that
there's data for it; it'll set up a receiving socket and the server process
will attempt to send.  Both will block until the message gets sent.  The
receiving end will parse that message to get the appropriate end.  The
sending end, meanwhile, will block waiting to receive a message.  The
receiving end will send a message telling the server process that it's
done, whereupon the server can unlock the mutex and get on with delivering
the *next* such signal, while the room process deals with its player
threads and gets ready to catch the next signal passed its way.

This way, we know that, because the sendmsg/recvmsg calls are blocking, we
are synchronized between the two processes.  Because of the mutex only one
room process will be ready to recvmsg() at any given time, since catching
that message happens only in the signal handler.

So I have two questions: A) will this work, or is there some blindingly
obvious race condition I overlooked, and B) is there a better way to do
this? 

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman