|Problems? Is your data what you think it is?|
Re^3: Replacing closures (to work around threads crash)by BrowserUk (Pope)
|on Nov 22, 2004 at 09:39 UTC||Need Help??|
Having now looked at the code in Net::Telnet around line 1987, I do understand your dilemma. I should have looked before, all the clues needed were present in your OP--but I didn't. Sorry.
That code, the evaled subs forming closured over lexical arrays combined with signals, pseudo-signals and timeouts (via alarm which wasn't implemented on Win32 until recently; and which I've never managed to get to do anything sensible) along with localise globals et al, is probably the most thread-unfreindly I have seen. That you are running on an SMP box may well be the straw that broke the camel's back.
The only suggestion I have is that you try applying the : shared atribute to every closed over variable/array in the module, and apply the lock( @closed_over ); wherever you see a closure being referenced (especially modified).
Both of these would become noops when the module was used in a non-threaded environment, so shouldn't affect it's operation there.
I have no way to try this idea out, so it is total speculation as to whether it would make one iota of difference.
In the absence of my having an SMP box and 2 or 3 places I could Telnet into, I have to accept (however reluctantly :) that castaway's suggestion that maybe a non-threaded solution is the right way to go for this, at least until the experts have applied their tuits to the underlying cause of the problem.
Examine what is said, not who speaks."But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon