[MTOS-dev] Background Task Change

[Byrne Reese]

The scripts should be compatible - but that is the complexity of the module
- how to bootstrap or override Perl's core routines to work within the
context of a web server.


On 2/13/08 3:04 AM, "Hirotaka Ogawa" <hirotaka.ogawa at gmail.com> wrote:

> On Feb 13, 2008 4:00 PM, Byrne Reese <byrne at sixapart.com> wrote:
>> Did you guys ever hear of the project I started at Six Apart called
>> mod_perlite? The concept was to model a stateless apache module for process
>> perl scripts based upon mod_php.
>> 
>> In this implementation, the Perl interpreter would be loaded into Apache's
>> memory space and would be spawned into threads by apache itself. No forking
>> required.
> 
> I don't know well about mod_perlite, but actually I'm confused.
> 
> PHP5 scripts have almost same semantics both on mod_php and mod_cgi +
> /usr/bin/php5.  On the other hand, as of Perl, mod_perlite plays the
> role of mod_php for perl?  And yet, mod_perlite does not require
> forking, but mod_cgi + /usr/bin/perl requires forking?  If so, scripts
> for mod_perlite are not compatible with those for mod_cgi +
> /usr/bin/perl...
> 
> Is this fact or just my misunderstanding?
> 
>> The theory is that this would of course be a lot faster. Aaron Stone, an
>> engineer at Six Apart, was helping me with the project (read: he did all the
>> work), but we are still not finished. Is there interest in exploring this
>> option further on this group?
>> 
>> Byrne
>> 
>> 
>> 
>> On 2/12/08 10:42 AM, "Reed A. Cartwright" <reed at scit.us> wrote:
>> 
>>> Hirotaka Ogawa wrote:
>>>> 
>>>> I wonder about the feasibility of doing something after closing
>>>> connection, especially for CGI.  No doubt, it'll be feasible for
>>>> FastCGI.
>>> 
>>> Yeah, it looks like the only way to do appendix tasks with CGI is to
>>> fork.  Oh well, one more reason to go to FastCGI.
>> 
>> 
>> 
> 
>