Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Perl 5.8.2 thread is worse - more findings from today

by liz (Monsignor)
on Jan 01, 2004 at 11:59 UTC ( #318104=note: print w/ replies, xml ) Need Help??


in reply to Perl 5.8.2 thread is worse - more findings from today

Bad news in the new year, I'm afraid. The bug is known, pretty old, and won't get fixed by 5.8.3. And I think I need to retract my comment about the communication between p5p and ActiveState being "suboptimal".

This came by on p5p yesterday:
list-post: <mailto:perl5-porters@perl.org> From: Jan Dubois <jand@ActiveState.com> Subject: Re: threads::shared::queue; Date: Wed, 31 Dec 2003 11:19:58 -0800 On Wed, 31 Dec 2003 17:10:12 +0000, Nicholas Clark <nick@ccl4.org> wrote: >I guess that it was overlooked. It actually had been committed: http://public.activestate.com/cgi-bin/perlbrowse?patch=17476 Unfortunately it has been backed out again: http://public.activestate.com/cgi-bin/perlbrowse?patch=18615 And the original problem, of course, is back. :( It seems like an impossible problem: you cannot allocate the ithread* structure from the Perl heap if you need to access it after the Perl heap has already been destroyed. I *think* we may get this working by just deferring the perl_free() ca +ll and not the perl_destruct(). perl_free() should not access any thread specific information, so it shouldn't need the THREADSPECIFIC setup. But I haven't actually tested this yet. But I think you don't want to mess with this until after the 5.8.3 release. Just put a note into KNOWN ISSUES that detached threads are still not supported on Windows. >I can't find any trace of this patch on p5p - is the Cc: to p5p new, +and the >rest of this thread was a private discussion? I'm curious as to what +the >original problem was. >(and what the patch looks like before it got quoted multiple times) Yes, it was a private thread between Arthur, Jarkko, Stacy Maughan and me, someone else in October 2002 (over a year ago). The problem affects only detached threads on Perl compiled with PERL_IMPLICIT_SYS. In that case PerlMemShared_free() is called indirectly through PL_Mem, which is freed by perl_destruct(). The patch delayed destruction of Perl until after the thread informati +on struct has been freed. Original bug report: | > To: arthur@contiller.se | > Subject: threads::shared::queue; | > | > I've compiled Perl 5.8.0 RC2 on Windows 2000 pro (and Win XP home) + with | > the Borland 5.5.1 compiler.  When I run perl code like that listed + | > below, I usually get 1 or 2 exceptions like: | > | > The instruction at "0x0127131c" referenced memory at "0x0137bbf0". +  The | > memory could not be "read".  | > | > from perl.exe (I think XP referenced threads.dll).  I think it is +a | > bug, but then again, maybe I am doing something wrong.  If you nee +d | > help tracking this down on my platform, I can attempt to help, but + I | > don't have any experience debugging perl, so it may take awhile fo +r me | > to come up to speed. | > | > Thanks, | > Stacy | > | > use threads; | > use threads::shared; | > use threads::shared::queue; | > | > my $q = new threads::shared::queue; | > | > for (1..20) { | >         $q->enqueue (int(rand 20)); | > } | > | > while ($q->pending) { | >         threads->create("WasteTime")->detach; | >         sleep 1; | > } | > | > sleep 21; | > print "All done\n"; | > | > sub WasteTime | > { | >         my $t= $q->dequeue; | >         print "sleeping for $t seconds\n"; | >         sleep $t; | >         print "Done sleeping for $t seconds\n"; | > } | > Cheers, -Jan

Now, I could envision a temporary hack which would use Thread::Exit and that would steal threads->detach to do nothing except marking it as "detached", and stealing threads->new to join() all the threads marked as "detached", so that at least the memory would be freed of the finished threads. I could also put this into a seperate module, e.g. Thread::Detach, which would disable itself for future versions of Perl where this problem would fixed on Win32.

Would that help?

Liz


Comment on Re: Perl 5.8.2 thread is worse - more findings from today
Download Code
Re: Re: Perl 5.8.2 thread is worse - more findings from today
by BrowserUk (Pope) on Jan 01, 2004 at 14:50 UTC

    It rather sounds like they should be using Thread Local Storage*, instead of Global Memory* or Heap memory*. The problem is, the design of perl's memory management doesn't make it easy to use multiple memory allocation strategies for different portions of the interpreter.

    *links won't work correctly unless your browser pretends to be (or is) IE or netscape.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://318104]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2015-07-05 05:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (60 votes), past polls