in reply to Re^2: A suicidal parent OR death of a forking server (Use threads)
in thread A suicidal parent OR death of a forking server

Thanks. It does have limitations thought. Specifically, it will only handle low 10s of concurrent connections before memory becomes an issue. And even if you keep within those levels of concurrency, if the connections are short-lived and made at high speed, it will be CPU-expensive.

But for the OPs low concurrency, long-lived connections application, it is remarkably simple and stable.

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.
"I'd rather go naked than blow up my ass"
  • Comment on Re^3: A suicidal parent OR death of a forking server (Use threads)

Replies are listed 'Best First'.
Re^4: A suicidal parent OR death of a forking server (Use threads)
by observer111 (Novice) on Feb 24, 2010 at 02:41 UTC
    Thanks for the info, which is good to know. I'm using a server based on your example above to control a pool of threads (using Thread::Pool::Simple) with perl 5.10.1, and don't need much concurrency etc., with this controller at least. I'm just hoping this will play nice with Thread::Pool::Simple. Thread::Pool::Simple tested fine with no leakage warnings... About to find out, I reckon.
[reply]

      If you are using Thread::Pool::Simple, you are not basing your code on my example above.

      My limited experience of that module is all negative.

      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]

        But I believe I am doing exactly that.

        Imagine, for a moment the following scenario. I pinched your code above, which makes a simple way to control things. Other things - a black box. So I can send commands to your threaded example above (or something similar to it), like this: 

          http://localhost:7070/startjobs

  http://localhost:7070/canceljobs

        [download]
        etc.

        Now, in my application, the black box controlled by your threaded server example, are jobs started and canceled (worker threads managed by Thread::Pool::Simple). They are different threads than the threads that are implementing the IO::Socket::INET -based command server. (Different in that they are doing different things; pooled worker threads, versus the threads used in the IO::Socket::INET command server itself. Ultimately they are all threads.)

        Hmmm, I wonder if that is more clear than before?

[reply]
[d/l]

In Section Seekers of Perl Wisdom