http://www.perlmonks.org?node_id=1080207


in reply to Using Coro with Telnet

instead of threads.

What changed in the four years since Working in parallel?


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.

Replies are listed 'Best First'.
Re^2: Using Coro with Telnet
by mpapec (Novice) on Mar 29, 2014 at 16:36 UTC

    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.
        What would you suggest in case where opened telnet session should remain for all future communication?