|There's more than one way to do things|
Re^3: Using Coro with Telnetby BrowserUk (Pope)
|on Mar 29, 2014 at 19:39 UTC||Need Help??|
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.