APM: fork on windows / long-running process and cgi

[Montgomery Conner]

As I understand Perl's fork() corresponds to the OS system call for *nix
distros... since there is no equivalent system call on Windows, fork() will
not work.  The ActiveState
<http://www.xav.com/perl/lib/Pod/perlfork.html>site includes some
information on fork() emulation for Windows:

The fork() <http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork>emulation
is implemented at the level of the Perl interpreter. What this
means in general is that running
fork()<http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork>will
actually clone the running interpreter and all its state, and run the
cloned interpreter in a separate thread, beginning execution in the new
thread just after the point where the
fork()<http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork>was
called in the parent.

I would assume that using this mechanism will incur the memory hit that
comes with duplicating the entire Perl interpreter for each call to fork().
You would have to test this to be certain...


Have you worked with the POE multitasking framework before?  I've found that
it is a useful (and fun!) alternative when I need a multitasking application
on Windows (or ever!).  By writing a simple web-server in
POE<http://search.cpan.org/search?query=poe&mode=all>(a truly trivial
task) you'd have a multitasking non-blocking application
that could listen and delegate appropriately.  Check-out the cookbook at the
project homepage for some ideas: http://poe.perl.org/


Good Luck!
Montgomery


On 2/8/07, Sam Foster <austin.pm at sam-i-am.com> wrote:
>
> so what is the skinny with fork on windows? No, not ever, yes with some
> workarounds, yes with a particular distribution of perl for win32s?
>
> I'm trying to put a web front-end on a build process - that may take a
> while. Ideally my initial request would kick off the build, and later
> requests would check on its status and finally pick up the output and
> send it or a link to it back to the client.
> I'm developing on and will ultimately be deploying to a windows xp box
> with apache and activestate's perl.
>
> So, it would seem that I should fork to kick the process off, send back
> a "working..." message as a response and close stdout in the parent
> process.
> The child process goes on working, putting output from the build script
> into a file.
>
> The client would keep polling every few seconds to check status, and
> grab and respond with the build script output, which will finally
> include a link to where the user can download a zip of the output.
>
> This is just for internal usage, and wont get high traffic. Concurrent
> requests are possible, but honestly quite unlikely. In fact, depending
> on the load on the server, the build usually finishes inside a minute so
> I could probably keep it simple and just sit and wait for the response -
> but I'd like to know what my options are. I do need input (config data)
> from the user so I cant just schedule this and run it nightly or
> something.
>
> Oh, and this is supposed to be a fun diversion from my real job, so if
> I'm trying to make it too complicated that's why :)
> thanks for any thoughts
> Sam
>
> _______________________________________________
> Austin mailing list
> Austin at pm.org
> http://mail.pm.org/mailman/listinfo/austin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/austin/attachments/20070208/46f84c4e/attachment.html