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.
| [reply] |
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] |