child and parent process communication

[techcode]

I've been hired to to extend some system that is essentially a forking server. Parent wait's for a connection, once detected it forks off the child and let's it handle it's business (login, process requests ...).

One of the modifications requested is that they can order it to drop some connection (all connection for one user - as there can be more than one connection/child for one user). As it is in that business, everyone keeps open connections, even if they have nothning to send, and just enquire link commands every x seconds (keep alive ping). The business is SMS providing (wholesale of SMS's).

As it's only the child knowing what user is logged in it, I was thinking of setting a shared memory key to username/id to be dropped, and sending a signal (say SIGUSR1) to program group. Childs would process SIGUSR1 and check if it's their user, and if it is, drop the connection.

But I was also thinking on being able to call functions from/in parent (or child) and pass a few parameters. Existing mechanisms such as pipes seem like a way too complicated as I would need to implement a lot of surounding code. Check for anythnig in the pipe ...

A perlish idea I have to do that, is to set a shared variable to say "function('param1', 234);" and signal the parent/child(s) who would simply EVAL that - would that even work? Anyone used somethnig like that?

Any other, simple way of calling functions from another process, where you "control" (can change code) both sending/receiving sides.

[shmem]

You could set up your inter process communication via SysV message queues - see perlipc. Yes, that would mean sending function names and parameters as strings. Another (a bit more involved) option is using POE and its Inter-Kernel Communication.

[cdarke]

Whatever method you use, shared memory or message queues, you still have a synchronisation issue. Personally I have used named pipes (FIFOs) because they are simple - really.
You need to indicate which child process the message is for. That can be done with message queues by using the child's PID as the type, or you could append the PID to a FIFO or shmem name. If you try to use one communial area then there are scheduling and synchronisation issues.
An alternative to using signals is to have a thread doing nothing but waiting on communication from the parent - most of the time it will be blocked. I have used this method, but not in Perl.

[jbert]

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.

[zentara]

It would be easy if you could switch to threads. :-) Interthread communication is easy.

One possible forked solution would be to include a control socket( on some local port) in every fork, in recv mode, and add that to the listening select array in the forked server. Then if the forked server reads it's id on the control socket, it should disconnect and close it's socket.

I'm not sure I understand the problem fully, but couldn't you let the server keep a hash( database) of all live connections, and include the username and number of logons, remote ip addresses, and the socket filehandles assigned. Then if the count exceeded 1, send a control code thru the control socket to close those connections?

[tmaly]

I have used POE for this same task. Using a combination of POE::Component::IKC for client server communication and POE::Component::Generic to spawn workers from the server