Your SIGUSR1 idea is OK, but doesn't scale nicely and you'll get a thundering herd of processes all waking up and checking the shared mem area. It'll be N^2 with your number of connections (since you have N procs and presumably O(N) signals).
IMHO, you should open a pipe before the fork and have the child write the userid back to the parent (and then close off the pipes). With a single one-way message, you'll avoid any difficult deadlock situations.
The parent just needs to add it's end of the pipe to your existing select/poll loop and do a read+close (or you'll leak fds) when it gets the info it needs.
In reply to Re: child and parent process communication
by jbert
in thread child and parent process communication
by techcode
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |