Re: Replacing closures (to work around threads crash)

Is there an alternative way to replace closures with something else?

The trouble with your question, beyond that like others, I cannot reproduce your problem, is that your example code doesn't show why you are trying to use closures. That is to say, devoid of the original context, your example code doesn't make any sense (to me). It makes it very hard to recommend an alternative, when it's not clear for what purpose you are trying to use them in the first place.

In your example, you are closing over a local, unshared array. That means each thread will get it's own copy of that array. However, it's not clear to me what purpose that array will serve?

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

Comment on Re: Replacing closures (to work around threads crash)

Replies are listed 'Best First'.
Re^2: Replacing closures (to work around threads crash) by eyepopslikeamosquito (Archbishop) on Nov 22, 2004 at 08:27 UTC
your example code doesn't show why you are trying to use closures I'm not trying to use closures myself. I am using the Net::Telnet module and Telnet.pm uses closures in a number of different places. My main headache is that I don't understand (nor really want to understand ;-) Telnet.pm, I just want it to stop crashing. So I'm looking for a "safe" way of getting rid of the closures without having to go to the bother of actually understanding Telnet.pm. BTW, I manufactured the above test program to get a repeatable (yeah, I know, but, hey, it's repeatable for me ;-) and quick crash to make debugging easier. The original program crashed intermittently once an hour or so, which was a real pain to debug -- the clue re closures was got from the "Free to wrong memory pool at Telnet.pm line 1987" message that accompanied most (but not all) the original crashes. Update: Thanks to everyone for reporting the lack of crashes. After further testing, it seems the above test program always crashes on multi-cpu machines yet never crashes on single CPU ones (at least that's what I see).	[reply]
Re^3: Replacing closures (to work around threads crash) by BrowserUk (Patriarch) on Nov 22, 2004 at 09:39 UTC
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	[reply] [d/l] [select]
Re^3: Replacing closures (to work around threads crash) by castaway (Parson) on Nov 22, 2004 at 08:40 UTC
Can you give a short example actually using Net::Telnet and threads? Do you actually need to run Net::Telnet inside a thread? Maybe you need IO::Select instead? C.	[reply]
Re^4: Replacing closures (to work around threads crash) by eyepopslikeamosquito (Archbishop) on Nov 22, 2004 at 08:53 UTC
I would not have chosen threads. The team who designed the application stress tested it (with no crashes) -- then went on holiday. When it ran up on a very large customer multi-processor box it started crashing intermittently and I was asked to investigate. I suppose a non-threaded solution is an option, but, given the size of the system (and my lack of tuits) it won't happen quickly. Anyway, the good news is that by replacing the closures, I've got the crashes to go away. I've also got them to go away by crudely hacking Dave Mitchell's closure patch (Change 23433 by davem on 2004/10/29 21:04:17) into our Windows build (this patch is not in Perl 5.8.x yet because it breaks the Windoze build -- see "Smoke [5.9.2] 23450" thread on p5p). Update: Dave's patch has been fixed for Win32 by change 23499.	[reply]


Perl: the Markov chain saw
	PerlMonks