Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
What I'm interested in is why I can't reproduce that problem. And if
you could come up with an explicit test that exposes that problem
clearly and exercises just that, it's a good idea to add it to the
test suite, so in the future we don't accidently "optimise" it away,
when doing some refactoring.
Coming up with a test will be difficult, because the behavior most likely depends on how the the pthreads are created & scheduled. I/we probably need to go through the callbacks & ithread code in mp2 to make sure we're calling PERL_SET_CONTEXT as often as needed.
Actually, it's not very simple to just do that and now that I think of it, your patch that I said it was OK may need more work. When you change the global context, you can't leave it set if you switch to a different interpreter. i.e. when you are done with the interpreter and you put it back into the pool, you need to restore the previous global context to whatever it was before (most likely it'll be the parent perl).
The whole issue is very sensitive, and it's usually win32 that has a problem with it due to the nature it's memory allocator/deallocator works, so we really need to add tests that break before trying to change anything.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
