Re^2: Replacing closures (to work around threads crash)

[eyepopslikeamosquito]

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

[BrowserUk]

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.

[castaway]

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.

[eyepopslikeamosquito]

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.