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

[liz]

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:[e-mail]>
From: Jan Dubois <[e-mail]>
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 <[e-mail]>
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: [e-mail]
| > 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

[BrowserUk]

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.