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 :)

Yes, I was hopping for some magic, or to be able to lie{1} to Net::Telnet so it would use Coro::Socket{2} or Coro::Handle{3}.
As it seems Net::Telnet{4} uses IO::Socket, so it looks like it might be abused in such way. :)

{1} http://www.perlmonks.org/?node_id=1039413
{2} http://search.cpan.org/~mlehmann/Coro-6.33/Coro/Socket.pm
{3} http://search.cpan.org/~mlehmann/Coro-6.33/Coro/Handle.pm
{4} http://cpansearch.perl.org/src/JROGERS/Net-Telnet-3.04/lib/Net/Telnet.pm

instead of threads.

What changed in the four years since Working in parallel?

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).

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.