in reply to Backgrounding (daemonizing?) a Net::server

Basicaly, you need a variable wait - one that will return once the server is ready to process requests.

Does the server open it's socket at the end of initialization (i.e. when it's ready to process requests?) If so, you could write a very simple script that just tries to open the socket.

If it gets "connection refused" it waits a second, if not, it exits - since the server is now ready to talk to your real client.

If it opens the socket much before it's ready to talk, does it give any other indication when it's ready? If not, perhaps you could write a very simple client (just enough to open a connection, perform the simplest operation and close the connection) - and start the real client once the simple one succeeds.

  • Comment on Re: Backgrounding (daemonizing?) a Net::server

Replies are listed 'Best First'.
Re: Re: Backgrounding (daemonizing?) a Net::server
by PetaMem (Priest) on Mar 28, 2004 at 11:42 UTC
    I thought about this too (long ago), but this approach has two problems:
    1. As during development happens, the server may crash, leaving an open socket. Only the server has the detection routine to clean up a left socket after its unsuccessfull predecessor-instance.
    2. You speak of a sleep-replacement, which means polling. I don't like polling. :-)

    Bye
     PetaMem
        All Perl:   MT, NLP, NLU

      Well, the only non-polling way I can think of is for the server to call the client. Which is kinda backwards, isn't it?

      I don't like polling in general either, but one has to have a sense of proportion. A process that polls once per second for, say 10 seconds (doing sleep 1 each time), is going to create much less engine load than a process that polls in a tight, milisecond loop.

      But you don't need a tight loop - if the server runs for an extra second before the first client starts, nothing bad will happen.

      On the other hand if you insist on creating a complicated solution just to avoid polling, you will needlessly complicate the server and spend much, much more of your time than you will save with the automated startup script.