perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <torsten.foert...@gmx.net>
Subject Re: modperl - quo vadis?
Date Fri, 04 Feb 2011 08:37:27 GMT
On Friday, February 04, 2011 00:38:25 Philip M. Gollucci wrote:
> >>> - big: refactor threading code
> 
> I'd loved to see your thread branch merged in.

me too, that would be a start. That branch works here in production. It works 
on my linux with and without threads. The main obstacle for me to move forward 
is windows. Would be good to test it there before the merge.

But here I am already failing on the preliminaries:

  http://www.gossamer-threads.com/lists/perl/porters/260496#260496

Hence the question about windows.

I have got a win7 oem version with a new computer. My next try would be to 
install that thing in a virtual machine and try again. But I wouldn't mind if 
someone with more windows wits jumps in.

> >>>  * make -Dusemultiplicity -Uuseithreads possible
> 
> I'm not really sure this is a big gain, for a tremendous amount of effort.

multiplicity is about multiple interpreters, threads about synchronization. 
For +Parent with prefork we don't need the latter. But I agree it's probably 
not a big win.

Perhaps it could be a by-product of the general refactoring if kept in mind.

> >>> - small: drop the tied-IO code and refactor/simplify the perlio stuff.
> 
> Yes!
> 
> >>> - implement a way to untie %ENV after fork() in a handler
> 
> Thats a rough one b/c of the way its coded.  see also local %ENV bombing.

I have feared someone would say that. I had a look at the code some time ago 
and yes, I think so too.

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message