You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/01/09 01:00:32 UTC
Re: early perl startup in vhost on win32
Stas Bekman wrote:
> Steve Hay wrote:
>
>> Stas Bekman wrote:
>>
>>> Also, can you please get the trace, after commenting out all the
>>> irrelevant config from httpd.conf, leaving only the config needed to
>>> reproduce the problem? It'll make the trace much more useful. Thanks
>>> Steve.
>>
>>
>>
>> I've reduced the httpd.conf file to just this (!):-
>>
>> =====
>> LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
>> ServerName localhost:8529
>> Listen 8529
>> ServerRoot C:/Temp/modperl-2.0/t
>> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>> LogLevel debug
>> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
>> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
>> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
>> PerlSwitches -IC:/Temp/modperl-2.0/t/response
>> Listen 8542
>> <VirtualHost _default_:8542>
>> PerlOptions +Parent
>> </Virtualhost>
>> PerlLoadModule TestDirective::perlloadmodule
>> =====
>>
>> The server still crashes on startup, even when started with the "-t"
>> switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
>> this minimal configuration.
>>
>> If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
>> above the <VirtualHost> then the "-t" test passes OK (the only output
>> is "syntax OK"). The server still doesn't start, though -- without
>> the "-t" switch it crashes in the same way as before (i.e. the "Free
>> to wrong pool" error). Here's the (much shorter) stacktrace from that
>> crash:
>
>
> The good news is that with the short config you posted above, I'm now
> able to reproduce the segfault, though a totally different one (in
> PerlLoadModule as well). I hope that the two have the same origin.
Steve, Randy, what's the status with this +Parent issue. I was carried away
with other issues and now that I come back I no longer can reproduce the
problem, which I seemed to 3 months ago. Do things any different with the
current mod_perl cvs?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>>Yes, that's a known problem in perl threads. Try replacing detach call with join:
>>
>
> Yeah, that fixes it.
Thanks, Steve. I've committed it (to my local rep).
Kurt on the modperl list has just reported a similar problem (free the wrong
pool), looking forward to his details. May be this time I'll be lucky and be
able to reproduce it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>But I don't get the segfault.
>>>
>>>I'd like to explore the possibility that we have a need for CLONE in Perl
>>>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>>>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>>>needed. If you don't know what CLONE is please see:
>>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>
>>>
>>>
>>I had a look at Example-CLONE. When I run "nmake test" it passes all
>>tests successfully, but then I get an application error popup, and it
>>spits out "A thread exited while 2 threads were running" on the
>>console. It's OK if I run the two tests, basic.t and threads.t,
>>individually.
>>
>>
>
>Yes, that's a known problem in perl threads. Try replacing detach call with join:
>
Yeah, that fixes it.
- Steve
>
>
>Index: t/threads.t
>===================================================================
>RCS file: /home/stas/cvs/modules/Example-CLONE/t/threads.t,v
>retrieving revision 1.1
>diff -u -r1.1 threads.t
>--- t/threads.t 31 Dec 2003 05:40:32 -0000 1.1
>+++ t/threads.t 12 Jan 2004 17:17:25 -0000
>@@ -31,7 +31,7 @@
>
> # as the new threads are spawned they will inherit the count from the
> # main thread
>-threads->new(\&read_test)->detach for 1..$threads;
>+threads->new(\&read_test) for 1..$threads;
>
> sub read_test : locked {
> for my $count (1..2) {
>@@ -42,8 +42,5 @@
> }
> }
>
>-# workaround the situations where the main thread exits before the
>-# child threads, which shouldn't be a problem since all threads are
>-# detached, but something is broken in perl
>-select(undef, undef, undef, 0.25); # sleep 0.25sec
>+$_->join() for threads->list();
>
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>
>
>
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:44 -0800 1/21/04, Stas Bekman wrote:
>
>>> No, he did say that. ;-)
>>
>> so no problemo then. Go for it Liz.
>
>
> Eh... tuits? I won't have hardly any until at least the summer... ;-(
How about moving to AU, it's summer there already ;)
NZ is another great choice ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:44 -0800 1/21/04, Stas Bekman wrote:
>>No, he did say that. ;-)
>so no problemo then. Go for it Liz.
Eh... tuits? I won't have hardly any until at least the summer... ;-(
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:16 -0800 1/21/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>>> I guess I could implement this in my test script using a simple
>>>> semaphore (shared variable), making sure that all callbacks pull
>>>> down that semaphore just before they are done and having the main
>>>> thread block till that semaphore gets to 0. e.g. your Running
>>>> implementation could drop the other dependencies list and just
>>>> override threads::create to wrap it in a semaphore up and down calls
>>>> around the callback.
>>>
>>> Indeed. Don't forget that you need to steal threads::new as well ;-)
>>
>> isn't one the alias of the other?
>
>
> Yes. But if you steal "create" like:
>
> *threads::create = sub {};
>
> then threads::new is still pointing to the old, unwrapped sub. This
> caught me off guard with Thread::Exit as well, as the CHANGELOG will
> tell you... ;-)
Yup ;)
>>> Well, and that's exactly the conundrum: any work done on threads may
>>> well only appear in blead (and not in 5.8.4). How many people use
>>> blead on production systems?
>>
>> I remember sky saying that threads.xs will be released on CPAN. oh was
>> I dreaming
>
>
> No, he did say that. ;-)
so no problemo then. Go for it Liz.
>>> "If you want to block until all threads have finished, you will have
>>> to do it yourself" was Jarkko's decision.
>>
>> OK, I didn't remember that. In which case threads should have
>> running() or similar, but not call it by itself.
>
> ??? You mean, threads::running should exist by default in threads:: ?
I mean the method should be in the core, but only used if called by the user.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:16 -0800 1/21/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>>I guess I could implement this in my test script using a simple
>>>semaphore (shared variable), making sure that all callbacks pull
>>>down that semaphore just before they are done and having the main
>>>thread block till that semaphore gets to 0. e.g. your Running
>>>implementation could drop the other dependencies list and just
>>>override threads::create to wrap it in a semaphore up and down
>>>calls around the callback.
>>Indeed. Don't forget that you need to steal threads::new as well ;-)
>isn't one the alias of the other?
Yes. But if you steal "create" like:
*threads::create = sub {};
then threads::new is still pointing to the old, unwrapped sub. This
caught me off guard with Thread::Exit as well, as the CHANGELOG will
tell you... ;-)
>>Well, and that's exactly the conundrum: any work done on threads
>>may well only appear in blead (and not in 5.8.4). How many people
>>use blead on production systems?
>I remember sky saying that threads.xs will be released on CPAN. oh
>was I dreaming
No, he did say that. ;-)
>>"If you want to block until all threads have finished, you will
>>have to do it yourself" was Jarkko's decision.
>OK, I didn't remember that. In which case threads should have
>running() or similar, but not call it by itself.
??? You mean, threads::running should exist by default in threads:: ?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
>> I guess I could implement this in my test script using a simple
>> semaphore (shared variable), making sure that all callbacks pull down
>> that semaphore just before they are done and having the main thread
>> block till that semaphore gets to 0. e.g. your Running implementation
>> could drop the other dependencies list and just override
>> threads::create to wrap it in a semaphore up and down calls around the
>> callback.
>
>
> Indeed. Don't forget that you need to steal threads::new as well ;-)
isn't one the alias of the other?
>>>> The bottom line is that I don't want to see that error/warning
>>>> message in my programs. Ideas?
>>>
>>> Convince p5p that there should be a blocking call until all threads
>>> have finished. I tried to convince p5p about this and associated
>>> functionality about 18 months ago (if I remember correctly). I
>>> wasn't successful.
>>
>> Because perl-ithreads has lost its owner when Arthur has moved to ride
>> the ponie and no-one has stepped up to replace him. Until this happens
>> there is no point to talk to p5p about threads, besides core dumps,
>> because nobody is going to work on it.
>
>
> Well, and that's exactly the conundrum: any work done on threads may
> well only appear in blead (and not in 5.8.4). How many people use blead
> on production systems?
I remember sky saying that threads.xs will be released on CPAN. oh was I dreaming
>> May be you should try to port your modules into XS. It isn't very
>> complex and you can always ask p5p gurus if you have any questions. so
>> you could start with implementing that blocking call.
>> BTW, IMHO, that should be called by default by the parent thread,
>> users should need to call threads->running.
>
>
> No, that was _specifically_ vetoed by Jarkko 18 months ago. When _any_
> thread exits, it will take all other threads with it. Including if it is
> the main thread exiting. The thing is that one of the threads may never
> exit for whatever reason, and then you're stuck.
>
> "If you want to block until all threads have finished, you will have to
> do it yourself" was Jarkko's decision.
OK, I didn't remember that. In which case threads should have running() or
similar, but not call it by itself.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 00:59 -0800 1/21/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>>So I think we need to have a new blocking call that will prevent
>>>the main program/thread from exiting till all child threads are
>>>done.
>>Thread::Running solves this basically.
>> 1 while threads->running;
>I looked at the implementation. You are such a cheater, Liz ;) But
>hey, it works. Very cool.
*blush* ;-)
>I guess I could implement this in my test script using a simple
>semaphore (shared variable), making sure that all callbacks pull
>down that semaphore just before they are done and having the main
>thread block till that semaphore gets to 0. e.g. your Running
>implementation could drop the other dependencies list and just
>override threads::create to wrap it in a semaphore up and down calls
>around the callback.
Indeed. Don't forget that you need to steal threads::new as well ;-)
>>>The bottom line is that I don't want to see that error/warning
>>>message in my programs. Ideas?
>>Convince p5p that there should be a blocking call until all threads
>>have finished. I tried to convince p5p about this and associated
>>functionality about 18 months ago (if I remember correctly). I
>>wasn't successful.
>Because perl-ithreads has lost its owner when Arthur has moved to
>ride the ponie and no-one has stepped up to replace him. Until this
>happens there is no point to talk to p5p about threads, besides core
>dumps, because nobody is going to work on it.
Well, and that's exactly the conundrum: any work done on threads may
well only appear in blead (and not in 5.8.4). How many people use
blead on production systems?
>May be you should try to port your modules into XS. It isn't very
>complex and you can always ask p5p gurus if you have any questions.
>so you could start with implementing that blocking call.
>BTW, IMHO, that should be called by default by the parent thread,
>users should need to call threads->running.
No, that was _specifically_ vetoed by Jarkko 18 months ago. When
_any_ thread exits, it will take all other threads with it.
Including if it is the main thread exiting. The thing is that one of
the threads may never exit for whatever reason, and then you're stuck.
"If you want to block until all threads have finished, you will have
to do it yourself" was Jarkko's decision.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 17:23 -0800 1/20/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> One could argue that detached threads shouldn't be counted. But, as
>>> I said, a detached thread is also yanked from existence as soon as
>>> any other thread does an exit().
>>> Hope this explains it a bit.
>>
>> Thanks, Liz. But how do we deal with this problem. Should I always
>> finish threads programs with:
>>
>> $_->join() for threads->list();
>>
>> but that won't work with detached threads, since list() will return
>> only a list of non-detached threads.
>>
>> So I think we need to have a new blocking call that will prevent the
>> main program/thread from exiting till all child threads are done.
>
>
> Thread::Running solves this basically.
>
> 1 while threads->running;
>
> Note that this module uses a method of operation that suffered in tha
> last Apache module discussion: it creates additional methods in the
> threads:: namespace ;-)
I looked at the implementation. You are such a cheater, Liz ;) But hey, it
works. Very cool.
I guess I could implement this in my test script using a simple semaphore
(shared variable), making sure that all callbacks pull down that semaphore
just before they are done and having the main thread block till that semaphore
gets to 0. e.g. your Running implementation could drop the other dependencies
list and just override threads::create to wrap it in a semaphore up and down
calls around the callback.
> Mind you, I think this should be done in threads.xs, but I haven't build
> up the courage to undertake that.
It certainly should be done in threads.xs. It shouldn't be too hard to
implement. The accounting data could be stored in PL_modglobal (the global
hash/object per interpreter).
>> The bottom line is that I don't want to see that error/warning message
>> in my programs. Ideas?
>
>
> Convince p5p that there should be a blocking call until all threads have
> finished. I tried to convince p5p about this and associated
> functionality about 18 months ago (if I remember correctly). I wasn't
> successful.
Because perl-ithreads has lost its owner when Arthur has moved to ride the
ponie and no-one has stepped up to replace him. Until this happens there is no
point to talk to p5p about threads, besides core dumps, because nobody is
going to work on it.
May be you should try to port your modules into XS. It isn't very complex and
you can always ask p5p gurus if you have any questions. so you could start
with implementing that blocking call.
BTW, IMHO, that should be called by default by the parent thread, users should
need to call threads->running.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 17:23 -0800 1/20/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>One could argue that detached threads shouldn't be counted. But,
>>as I said, a detached thread is also yanked from existence as soon
>>as any other thread does an exit().
>>Hope this explains it a bit.
>Thanks, Liz. But how do we deal with this problem. Should I always
>finish threads programs with:
>
> $_->join() for threads->list();
>
>but that won't work with detached threads, since list() will return
>only a list of non-detached threads.
>
>So I think we need to have a new blocking call that will prevent the
>main program/thread from exiting till all child threads are done.
Thread::Running solves this basically.
1 while threads->running;
Note that this module uses a method of operation that suffered in tha
last Apache module discussion: it creates additional methods in the
threads:: namespace ;-)
Mind you, I think this should be done in threads.xs, but I haven't
build up the courage to undertake that.
>The bottom line is that I don't want to see that error/warning
>message in my programs. Ideas?
Convince p5p that there should be a blocking call until all threads
have finished. I tried to convince p5p about this and associated
functionality about 18 months ago (if I remember correctly). I
wasn't successful.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 10:15 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> At 10:00 -0800 1/12/04, Stas Bekman wrote:
>>>
>>>> % perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>>>> 1})->detach for 1..1'
>>>> A thread exited while 2 threads were running.
>>>
>>> Ah. That! That is considered to be correct behaviour (unless you're
>>> referring to the "2" instead of "1").
>>
>> What's correct about it? I've detached the threads and shouldn't get
>> any errors.
>
>
> The problem is not in the detach. the problem is that your program
> finishes before all the threads have finished. This was discussed
> extensively on p5p in the summer of 2002 prior to the 5.8.0 release. The
> problem is that a thread cannot continue if any other thread does an
> exit(). To indicate that you're doing that, the message occurs. Only
> problem is that the hidden thread that's used to store shared values, is
> counted as well.
>
> One could argue that detached threads shouldn't be counted. But, as I
> said, a detached thread is also yanked from existence as soon as any
> other thread does an exit().
>
>
> Hope this explains it a bit.
Thanks, Liz. But how do we deal with this problem. Should I always finish
threads programs with:
$_->join() for threads->list();
but that won't work with detached threads, since list() will return only a
list of non-detached threads.
So I think we need to have a new blocking call that will prevent the main
program/thread from exiting till all child threads are done.
The bottom line is that I don't want to see that error/warning message in my
programs. Ideas?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:15 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>At 10:00 -0800 1/12/04, Stas Bekman wrote:
>>>% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>>>1})->detach for 1..1'
>>>A thread exited while 2 threads were running.
>>Ah. That! That is considered to be correct behaviour (unless
>>you're referring to the "2" instead of "1").
>What's correct about it? I've detached the threads and shouldn't get
>any errors.
The problem is not in the detach. the problem is that your program
finishes before all the threads have finished. This was discussed
extensively on p5p in the summer of 2002 prior to the 5.8.0 release.
The problem is that a thread cannot continue if any other thread does
an exit(). To indicate that you're doing that, the message occurs.
Only problem is that the hidden thread that's used to store shared
values, is counted as well.
One could argue that detached threads shouldn't be counted. But, as
I said, a detached thread is also yanked from existence as soon as
any other thread does an exit().
Hope this explains it a bit.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 10:00 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> Oh? That's news to me. I was under the impression the problem only
>>> existed on Win32.
>>> Could you show me how to reproduce the problem on *nix?
>>
>>
>> % perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>> 1})->detach for 1..1'
>> A thread exited while 2 threads were running.
>
>
> Ah. That! That is considered to be correct behaviour (unless you're
> referring to the "2" instead of "1").
What's correct about it? I've detached the threads and shouldn't get any errors.
>> Besides, I find it worrying that we have a flurry of workaround
>> modules instead of trying to fix the core. Of course it's better than
>> nothing, but it all should really be fixed in the core.
>
>
> There is another bug with detach() in Win32 which can cause crashes. It
> was decided on p5p that it would _not_ get fixed for 5.8.3. So, that
> means at least 3 - 4 months of Windows users running into this. I have
> no doubt it will get fixed (actually, I'm assuming 5.8.4 in the source
> of Thread::Detach). Until then, Thread::Detach is a workaround if you
> don't want to change your source.
So I should remember to try to avoid using detach in my code. Thanks for the
heads up, Liz. Luckily in mp2 we don't quite need this feature.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:00 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>Oh? That's news to me. I was under the impression the problem
>>only existed on Win32.
>>Could you show me how to reproduce the problem on *nix?
>
>% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>1})->detach for 1..1'
>A thread exited while 2 threads were running.
Ah. That! That is considered to be correct behaviour (unless you're
referring to the "2" instead of "1").
>>>In any case, for my test using join instead of detach does the
>>>trick just fine.
>>Yes, but some people prefer to be able to use detach() at one point
>>in the future, hence my repair module. I thought it would just be
>>needed on Win32. If it is needed on more platforms, I would like
>>to know so that I can fix either the documentation and the internal
>>OS checks.
>Sure, but I have another workaround for my module and I don't want
>to create dependencies if I can avoid to.
Indeed.
>Besides, I find it worrying that we have a flurry of workaround
>modules instead of trying to fix the core. Of course it's better
>than nothing, but it all should really be fixed in the core.
There is another bug with detach() in Win32 which can cause crashes.
It was decided on p5p that it would _not_ get fixed for 5.8.3. So,
that means at least 3 - 4 months of Windows users running into this.
I have no doubt it will get fixed (actually, I'm assuming 5.8.4 in
the source of Thread::Detach). Until then, Thread::Detach is a
workaround if you don't want to change your source.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 09:37 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> You might also want to check out my Thread::Detach from CPAN:
>>
>> Thanks, Liz. But the problem exists not only on Win32. I can easily
>> reproduce it on linux.
>
>
> Oh? That's news to me. I was under the impression the problem only
> existed on Win32.
>
> Could you show me how to reproduce the problem on *nix?
% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep 1})->detach
for 1..1'
A thread exited while 2 threads were running.
>> So I don't think your doc is correct to say: "All of this happens on
>> Windows only and if the version of the Perl executor is known to have
>> the problem."
>
>
> Well, to my knowledge it was... I've never had any problems with
> detaching threads.
of course ;)
>> In any case, for my test using join instead of detach does the trick
>> just fine.
>
>
> Yes, but some people prefer to be able to use detach() at one point in
> the future, hence my repair module. I thought it would just be needed
> on Win32. If it is needed on more platforms, I would like to know so
> that I can fix either the documentation and the internal OS checks.
Sure, but I have another workaround for my module and I don't want to create
dependencies if I can avoid to.
Besides, I find it worrying that we have a flurry of workaround modules
instead of trying to fix the core. Of course it's better than nothing, but it
all should really be fixed in the core.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:37 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>You might also want to check out my Thread::Detach from CPAN:
>Thanks, Liz. But the problem exists not only on Win32. I can easily
>reproduce it on linux.
Oh? That's news to me. I was under the impression the problem only
existed on Win32.
Could you show me how to reproduce the problem on *nix?
>So I don't think your doc is correct to say: "All of this happens on
>Windows only and if the version of the Perl executor is known to
>have the problem."
Well, to my knowledge it was... I've never had any problems with
detaching threads.
>In any case, for my test using join instead of detach does the trick
>just fine.
Yes, but some people prefer to be able to use detach() at one point
in the future, hence my repair module. I thought it would just be
needed on Win32. If it is needed on more platforms, I would like to
know so that I can fix either the documentation and the internal OS
checks.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 09:17 -0800 1/12/04, Stas Bekman wrote:
>
>> Steve Hay wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> But I don't get the segfault.
>>>>
>>>> I'd like to explore the possibility that we have a need for CLONE in
>>>> Perl sections and PerlLoadModule next. I wish I had the segfault,
>>>> though. I need to think how to create it. But if I fail I'll try to
>>>> analyze whether we CLONE is needed. If you don't know what CLONE is
>>>> please see:
>>>> http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>>
>>>
>>> I had a look at Example-CLONE. When I run "nmake test" it passes all
>>> tests successfully, but then I get an application error popup, and it
>>> spits out "A thread exited while 2 threads were running" on the
>>> console. It's OK if I run the two tests, basic.t and threads.t,
>>> individually.
>>
>>
>> Yes, that's a known problem in perl threads. Try replacing detach call
>> with join:
>
>
> You might also want to check out my Thread::Detach from CPAN:
>
>
> http://search.cpan.org/~elizabeth/Thread-Detach-0.01/lib/Thread/Detach.pm
>
> that should allow you to keep your source code unchanged (just add
> Thread::Detach to PERL5OPTS).
Thanks, Liz. But the problem exists not only on Win32. I can easily reproduce
it on linux. So I don't think your doc is correct to say: "All of this happens
on Windows only and if the version of the Perl executor is known to have the
problem."
In any case, for my test using join instead of detach does the trick just fine.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:17 -0800 1/12/04, Stas Bekman wrote:
>Steve Hay wrote:
>>Stas Bekman wrote:
>>
>>>But I don't get the segfault.
>>>
>>>I'd like to explore the possibility that we have a need for CLONE
>>>in Perl sections and PerlLoadModule next. I wish I had the
>>>segfault, though. I need to think how to create it. But if I fail
>>>I'll try to analyze whether we CLONE is needed. If you don't know
>>>what CLONE is please see:
>>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>
>>
>>I had a look at Example-CLONE. When I run "nmake test" it passes
>>all tests successfully, but then I get an application error popup,
>>and it spits out "A thread exited while 2 threads were running" on
>>the console. It's OK if I run the two tests, basic.t and
>>threads.t, individually.
>
>Yes, that's a known problem in perl threads. Try replacing detach
>call with join:
You might also want to check out my Thread::Detach from CPAN:
http://search.cpan.org/~elizabeth/Thread-Detach-0.01/lib/Thread/Detach.pm
that should allow you to keep your source code unchanged (just add
Thread::Detach to PERL5OPTS).
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>But I don't get the segfault.
>>
>>I'd like to explore the possibility that we have a need for CLONE in Perl
>>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>>needed. If you don't know what CLONE is please see:
>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>
>
> I had a look at Example-CLONE. When I run "nmake test" it passes all
> tests successfully, but then I get an application error popup, and it
> spits out "A thread exited while 2 threads were running" on the
> console. It's OK if I run the two tests, basic.t and threads.t,
> individually.
Yes, that's a known problem in perl threads. Try replacing detach call with join:
Index: t/threads.t
===================================================================
RCS file: /home/stas/cvs/modules/Example-CLONE/t/threads.t,v
retrieving revision 1.1
diff -u -r1.1 threads.t
--- t/threads.t 31 Dec 2003 05:40:32 -0000 1.1
+++ t/threads.t 12 Jan 2004 17:17:25 -0000
@@ -31,7 +31,7 @@
# as the new threads are spawned they will inherit the count from the
# main thread
-threads->new(\&read_test)->detach for 1..$threads;
+threads->new(\&read_test) for 1..$threads;
sub read_test : locked {
for my $count (1..2) {
@@ -42,8 +42,5 @@
}
}
-# workaround the situations where the main thread exits before the
-# child threads, which shouldn't be a problem since all threads are
-# detached, but something is broken in perl
-select(undef, undef, undef, 0.25); # sleep 0.25sec
+$_->join() for threads->list();
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>But I don't get the segfault.
>
>I'd like to explore the possibility that we have a need for CLONE in Perl
>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>needed. If you don't know what CLONE is please see:
>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>
I had a look at Example-CLONE. When I run "nmake test" it passes all
tests successfully, but then I get an application error popup, and it
spits out "A thread exited while 2 threads were running" on the
console. It's OK if I run the two tests, basic.t and threads.t,
individually.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> I get a strange error with perl < 5.8.3 and the above config:
>
> failed to resolve handler `Apache::PerlSections'
> Syntax error on line 33 of /home/stas/apache.org/cvs/t/conf/httpd.conf:
> Modification of a read-only value attempted at
> /home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/DynaLoader.pm
> line 79.
> Compilation failed in require at
> /home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/XSLoader.pm
> line 93.
> Compilation failed in require at
> /home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
> BEGIN failed--compilation aborted at
> /home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
> Compilation failed in require at (eval 2) line 3.
>
> looked at line 79, and I can't see any readonly vars there, must be a
> shifted counter. will try to get this resolved first. But I don't get
> this error with 5.8.3 and it starts just fine for me.
Apparently Dynaloader needs to be preloaded. Will shortly commit the fix.
But I don't get the segfault.
I'd like to explore the possibility that we have a need for CLONE in Perl
sections and PerlLoadModule next. I wish I had the segfault, though. I need to
think how to create it. But if I fail I'll try to analyze whether we CLONE is
needed. If you don't know what CLONE is please see:
http://apache.org/~stas/Example-CLONE-0.02.tar.gz
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> I've just tried it with the current CVS and still get the old "Free to
> wrong pool" error:
>
> =====
> C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
> C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf.short
> -DAPACHE2 -DPERL_USEITHREADS
> Free to wrong pool 262828 not 863270.
> Note the errors or messages above, and press the <ESC> key to exit. 30...
> =====
:(
> Attached is a .tar.gz of the three files that I added which comprise the
> vhost tests, just so that we can be clear about what I'm testing here.
yes, but it fails before it tries to run the tests, so it's not really needed,
no? All you need is this short config file.
> I used a different httpd.conf.short file to the one quoted above:
>
> =====
> LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
> ServerName localhost:8529
> Listen 8529
> ServerRoot C:/Temp/modperl-2.0/t
> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
> LogLevel debug
> Listen 8530
> <VirtualHost _default_:8530>
> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
> PerlOptions +Parent
> <Perl >
> 1;
> </Perl>
> </VirtualHost>
> =====
>
> I think this conf file was produced a little later in the thread; it
> simplifies things even further by omitting the
> TestDirective::perlloadmodule bit.
I get a strange error with perl < 5.8.3 and the above config:
failed to resolve handler `Apache::PerlSections'
Syntax error on line 33 of /home/stas/apache.org/cvs/t/conf/httpd.conf:
Modification of a read-only value attempted at
/home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/DynaLoader.pm
line 79.
Compilation failed in require at
/home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/XSLoader.pm
line 93.
Compilation failed in require at
/home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
BEGIN failed--compilation aborted at
/home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
Compilation failed in require at (eval 2) line 3.
looked at line 79, and I can't see any readonly vars there, must be a shifted
counter. will try to get this resolved first. But I don't get this error with
5.8.3 and it starts just fine for me.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>
>>>>Also, can you please get the trace, after commenting out all the
>>>>irrelevant config from httpd.conf, leaving only the config needed to
>>>>reproduce the problem? It'll make the trace much more useful. Thanks
>>>>Steve.
>>>>
>>>>
>>>
>>>I've reduced the httpd.conf file to just this (!):-
>>>
>>>=====
>>>LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
>>>ServerName localhost:8529
>>>Listen 8529
>>>ServerRoot C:/Temp/modperl-2.0/t
>>>DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>>>LogLevel debug
>>>PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
>>>PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
>>>PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
>>>PerlSwitches -IC:/Temp/modperl-2.0/t/response
>>>Listen 8542
>>><VirtualHost _default_:8542>
>>> PerlOptions +Parent
>>></Virtualhost>
>>>PerlLoadModule TestDirective::perlloadmodule
>>>=====
>>>
>>>The server still crashes on startup, even when started with the "-t"
>>>switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
>>>this minimal configuration.
>>>
>>>If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
>>>above the <VirtualHost> then the "-t" test passes OK (the only output
>>>is "syntax OK"). The server still doesn't start, though -- without
>>>the "-t" switch it crashes in the same way as before (i.e. the "Free
>>>to wrong pool" error). Here's the (much shorter) stacktrace from that
>>>crash:
>>>
>>>
>>The good news is that with the short config you posted above, I'm now
>>able to reproduce the segfault, though a totally different one (in
>>PerlLoadModule as well). I hope that the two have the same origin.
>>
>>
>
>Steve, Randy, what's the status with this +Parent issue. I was carried away
>with other issues and now that I come back I no longer can reproduce the
>problem, which I seemed to 3 months ago. Do things any different with the
>current mod_perl cvs?
>
I've just tried it with the current CVS and still get the old "Free to
wrong pool" error:
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf.short
-DAPACHE2 -DPERL_USEITHREADS
Free to wrong pool 262828 not 863270.
Note the errors or messages above, and press the <ESC> key to exit. 30...
=====
Attached is a .tar.gz of the three files that I added which comprise the
vhost tests, just so that we can be clear about what I'm testing here.
I used a different httpd.conf.short file to the one quoted above:
=====
LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen 8530
<VirtualHost _default_:8530>
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlOptions +Parent
<Perl >
1;
</Perl>
</VirtualHost>
=====
I think this conf file was produced a little later in the thread; it
simplifies things even further by omitting the
TestDirective::perlloadmodule bit.
This is all now using Apache 2.0.48 and Perl 5.8.2.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.