mpapec has asked for the wisdom of the Perl Monks concerning the following question:
I would like to use multiple, long living Net::Telnet sessions in Coro environment instead of threads.
I've been reading http://search.cpan.org/dist/Coro/Coro/Intro.pod but couldn't find information relevant for my task. Is there some cookbook, or examples how to use telnet with Coro?
Re: Using Coro with Telnet
by basiliscos (Pilgrim) on Mar 29, 2014 at 10:52 UTC
|
AFAIK, Coro/AnyEvent do not bring asynchronous magic to any other perl module (e.g. Net::Telnet). So, if underlying library mechanics is blocking, they'll remain blocking with Coro.
That could be determined by module dependencies: if it does not depends on AnyEvent/EV, they are probably blocking.
Actually, in reality things could be a bit more complex, e.g. Mojolicious: it does not depends on AE/EV explicitly, but in can optionally use EV. That means, that you can use AE modules together with Mojolicious, if there is EV installed.
So, you probably should determine whether Net::Telnet supports non-blocking code style (aka depends on AE/EV); and if it is not, then find with that support or write the module by yoursef :)
| [reply] |
|
| [reply] |
Re: Using Coro with Telnet
by BrowserUk (Patriarch) on Mar 29, 2014 at 11:06 UTC
|
| [reply] |
|
Hi, I'm glad you've asked.
There are a few drawbacks to threads. First, I have to limit number of threads as they are consuming considerable amounts of memory.
Second, IO handles can't be shared between threads, so once my thread worker connect to remote address I have to use this particular worker for all
future communication, which doesn't go well along with worker pattern. http://www.perlmonks.org/?node_id=967149
Since workers are IO bound, I thought they could benefit from cooperative environment (everything is shared/no need for variable locking/use less memory).
| [reply] |
|
I have to limit number of threads as they are consuming considerable amounts of memory.
The memory footprint of threads can usually be dramatically reduced with very little effort.
IO handles can't be shared between threads, so once my thread worker connect to remote address I have to use this particular worker for all future communication,
Not so. IO handles can be reopened in multiple threads; though it is rarely useful to do so.
Almost always the desire to do so indicates a bad design.
which doesn't go well along with worker pattern. http://www.perlmonks.org/?node_id=967149
That argument makes no sense. The boss says, create a telnet connection to these machines and perform this/these tasks -- by queuing the relevant session information -- and the workers dequeue a set of instructions and perform them.
everything is shared
True. Everything is shared -- which means you have manage the problem of ensuring that different contexts do not trample all over each others private data.
/no need for variable locking
True. No need to lock since only one execution context can run at any given time.
Which means if you have a 16 core machine you're ignoring 93.75% of your potential cpu and wasting 10%+ of the one cpu you are utilising, perform crude context swapping in user level code; and another 5% fighting the system scheduler.
But if you really want to return to the mid-90s, Windows95-style of cooperative multitasking, with all of its inherent problems...
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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] |
|
|
|
|