Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
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 taking refuge in the Monastery: (13)
As of 2014-07-25 18:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (174 votes), past polls