in reply to Printing to all clients on a socket from a child process

The infinite loops role is to send out a keep alive signal on the socket to all the clients every X seconds.

One simple mechanism would be to have the child process (or thread) connect back to the listening socket and send a message every X seconds. Your existing code without modification would forward these to each of the clients as any other message. Though you might want to avoid sending stuff to the keep-alive client. Once you start discriminating about what messages you forward to what clients, the keep-alive just gets forward to all clients (except it's originator) as now.

Of course, the next step is likely to be to only send keep-alive messages to those clients that you haven't sent any message to (and perhaps, received a message from) for the last X seconds. It's at this point that the thread would come into it's own, as you can then use a shared hash to record the last time a message was sent to each client.

The keep-alive thread then wakes up every X/n (where n depends upon the resolution you require), scans the shared hash, and sends keep-alive messages, with a client identifier parameter, for each client who's time falls due within the next X/n period. Your main select loop will receive and forward these messages in the normal way.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re: Printing to all clients on a socket from a child process

Replies are listed 'Best First'.
Re^2: Printing to all clients on a socket from a child process
by Fredde87 (Initiate) on Mar 11, 2008 at 16:58 UTC
    I have tried this solution as a backup. There is only one problem with it which is that some of my functions can take up to a minute to complete. That means I wont get a keep alive until it finishes. Is there an easy way to get around that so that I still process the keep alives whilst one of my functions is running?
[reply]

      Simplistically, put the functions in a thread also. That also allows your select loop to remain responsive to other comings and goings.

      Of course, then you need to track what threads you've started on behalf of what clients. and that starts to complicate things a bit. You could have the function threads connect back to the listener to return results, but depending upon how many clients you have it could get expensive spawning threads for short processes.

      A better architecture, especially with ithreads, would be to have your longer running functions run in long-running threads with loops reading from function specific queues and writing back to a shared results queue for dispatch. The select loop uses a timeout and monitors the results queue using dequeue_nb().

      That's harder to describe than write, but if the tachnique interests you I could probably adapt your example to demonstrate it?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom