问题
I'm designing a server that will initialize by fork / exec'ing four "managers" (themselves server processes) and will then accept connections from clients, fork / exec'ing "slaves" to communicate with the clients. During their lifetimes, the slaves will establish connections with the managers and send them work requests.
My question is about starting up the managers. Each one may take some time to initialize (minutes) and I don't want the master server to proceed to accept clients until they've initialized. What would be the best way to do this? Should I explore having the managers signal the master server when they're ready? Should I have the managers make a socket connection to the master - probably on a different port than the one clients connect to - and send a message when ready? Or something else?
回答1:
I'd be very tempted to create one pipe before forking off the four managers. When a manager is ready, it can write its PID on the pipe and close it. The master server can delay opening its listening port until at least one of the managers has indicated that it is ready. If it gets EOF from the pipe before all the managers have reported ready for active duty, then it knows at least one of the managers failed to start and can take appropriate action (log errors and exit?). Messages written to a pipe are normally treated atomically; that is, if the message is short enough, what one process writes will not be interleaved with what another process writes.
For some variations, you could have one pipe per manager; then you have to decide how you're going to poll or select which of the pipes has a message waiting. You could decide that managers do not close the pipe after indicating that they're ready; they could keep it open, and write an appropriate 'PID ready' when ready, and other status messages ('PID exiting', 'PID too busy', 'PID taking coffee break', ...) later on.
There are a lot of other IPC mechanisms that could be used, each with its own set of advantages and disadvantages. A lot depends on what the managers need to communicate to the master (and whether the master needs to communicate with specific managers). Sockets could be used for sure; so could message queues. If your communication needs are simple, a semaphore set might work. And the list goes on.
回答2:
What you are thinking of are FIFO pipes. mknod is traditionally used to create them. The pipes have 2 file descriptors, one for reading, one for writing.... they can block on that if necessary...
来源：https://stackoverflow.com/questions/14049237/perl-communicating-with-a-fork-execed-process