develooper Front page | perl.perl5.porters | Postings from December 2003

Re: threads::shared::queue;

Thread Previous | Thread Next
From:
Jan Dubois
Date:
December 31, 2003 11:21
Subject:
Re: threads::shared::queue;
Message ID:
po56vvo01733ocgh82721qjmhma4ofu8uo@4ax.com
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() call
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 information
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 need 
| > 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 for 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


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About