in reply to controling the num of fork sessions

Is this the most elegant approach?
I can see this working ok for 10-20 servers, but for 2000 wouldn't a client/server architecture be more appropriate? What about having a listening process (rpc perhaps?) on each machine, and then whenever you need to feed it commands, your client can send messages to the servers in a simple loop.

For the way you're implementing it now, I would suggest maybe using Threads over forking new processes.

  • Comment on Re: controling the num of fork sessions

Replies are listed 'Best First'.
Re: Re: controling the num of fork sessions
by Anonymous Monk on Nov 27, 2000 at 05:37 UTC

    Thanks, and yes in a perfect world I would run it as a client / server process. However in this instance I am updating a minor portion of servers that I do not have complete say over. So I am attempting to use only existing items on the server side. (where I put "print" in my example I have a telnet proc that runs an EXE on the remote box)

    As for "threads" I am worried about the stability of it when running in a Windows NT environment.

    Thanks, BRN

[reply]

In Section Seekers of Perl Wisdom