<br>Sam, <br><br> Since this is not going to be generating high traffic (not needing to fork off alot), <br>you might just try Win32::Process::Create(). We have a product that does this <br>for each running build on windows and then round robins across non-blocking sockets
<br>within each process in order to avoid forking a bunch of times. Note that this is tricky<br>and you have to watch out for deadlocks or a single socket over-consuming all the processing time.<br> Our product is used for kicking off builds and maintaining information about it in a web UI.
<br>It's very flexible, and written in Perl / PHP / C with Eclipse and Visual studio plugins, the downside is it's a bit expensive if this is just a side thing.<br> Here's a link to one of our open-source competitors (not nearly the feature set and written in java it would appear, but it looks interesting):
<br> <a href="http://luntbuild.javaforge.com/">http://luntbuild.javaforge.com/</a><br><br><br> --Heath<br><br><div><span class="gmail_quote">On 2/9/07, <b class="gmail_sendername"><a href="mailto:austin-request@pm.org">
austin-request@pm.org</a></b> <<a href="mailto:austin-request@pm.org">austin-request@pm.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Send Austin mailing list submissions to<br> <a href="mailto:austin@pm.org">austin@pm.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://mail.pm.org/mailman/listinfo/austin">
http://mail.pm.org/mailman/listinfo/austin</a><br>or, via email, send a message with subject or body 'help' to<br> <a href="mailto:austin-request@pm.org">austin-request@pm.org</a><br><br>You can reach the person managing the list at
<br> <a href="mailto:austin-owner@pm.org">austin-owner@pm.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Austin digest..."<br><br><br>Today's Topics:
<br><br> 1. fork on windows / long-running process and cgi (Sam Foster)<br> 2. Re: fork on windows / long-running process and cgi<br> (Montgomery Conner)<br> 3. Re: fork on windows / long-running process and cgi (Sam Foster)
<br> 4. Re: fork on windows / long-running process and cgi<br> (Taylor Carpenter)<br> 5. Re: fork on windows / long-running process and cgi (Tim McDaniel)<br> 6. Re: fork on windows / long-running process and cgi (Sam Foster)
<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 08 Feb 2007 15:37:11 -0600<br>From: Sam Foster <<a href="mailto:austin.pm@sam-i-am.com">austin.pm@sam-i-am.com
</a>><br>Subject: APM: fork on windows / long-running process and cgi<br>To: "<a href="http://austin.pm">austin.pm</a>" <<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID: <<a href="mailto:45CB9807.6030509@sam-i-am.com">
45CB9807.6030509@sam-i-am.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>so what is the skinny with fork on windows? No, not ever, yes with some<br>workarounds, yes with a particular distribution of perl for win32s?
<br><br>I'm trying to put a web front-end on a build process - that may take a<br>while. Ideally my initial request would kick off the build, and later<br>requests would check on its status and finally pick up the output and
<br>send it or a link to it back to the client.<br>I'm developing on and will ultimately be deploying to a windows xp box<br>with apache and activestate's perl.<br><br>So, it would seem that I should fork to kick the process off, send back
<br>a "working..." message as a response and close stdout in the parent<br>process.<br>The child process goes on working, putting output from the build script<br>into a file.<br><br>The client would keep polling every few seconds to check status, and
<br>grab and respond with the build script output, which will finally<br>include a link to where the user can download a zip of the output.<br><br>This is just for internal usage, and wont get high traffic. Concurrent<br>
requests are possible, but honestly quite unlikely. In fact, depending<br>on the load on the server, the build usually finishes inside a minute so<br>I could probably keep it simple and just sit and wait for the response -
<br>but I'd like to know what my options are. I do need input (config data)<br>from the user so I cant just schedule this and run it nightly or something.<br><br>Oh, and this is supposed to be a fun diversion from my real job, so if
<br>I'm trying to make it too complicated that's why :)<br>thanks for any thoughts<br>Sam<br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 8 Feb 2007 18:45:02 -0600<br>From: "Montgomery Conner" <
<a href="mailto:montgomery.conner@gmail.com">montgomery.conner@gmail.com</a>><br>Subject: Re: APM: fork on windows / long-running process and cgi<br>To: "Sam Foster" <<a href="mailto:austin.pm@sam-i-am.com">
austin.pm@sam-i-am.com</a>><br>Cc: "<a href="http://austin.pm">austin.pm</a>" <<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID:<br> <<a href="mailto:e8c2cfe90702081645n299689ceg7113100323c41dac@mail.gmail.com">
e8c2cfe90702081645n299689ceg7113100323c41dac@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>As I understand Perl's fork() corresponds to the OS system call for *nix<br>distros... since there is no equivalent system call on Windows, fork() will
<br>not work. The ActiveState<br><<a href="http://www.xav.com/perl/lib/Pod/perlfork.html">http://www.xav.com/perl/lib/Pod/perlfork.html</a>>site includes some<br>information on fork() emulation for Windows:<br><br>
The fork() <<a href="http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork">http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork</a>>emulation<br>is implemented at the level of the Perl interpreter. What this<br>
means in general is that running<br>fork()<<a href="http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork">http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork</a>>will<br>actually clone the running interpreter and all its state, and run the
<br>cloned interpreter in a separate thread, beginning execution in the new<br>thread just after the point where the<br>fork()<<a href="http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork">http://www.xav.com/perl/lib/Pod/perlfunc.html#item_fork
</a>>was<br>called in the parent.<br><br>I would assume that using this mechanism will incur the memory hit that<br>comes with duplicating the entire Perl interpreter for each call to fork().<br>You would have to test this to be certain...
<br><br><br>Have you worked with the POE multitasking framework before? I've found that<br>it is a useful (and fun!) alternative when I need a multitasking application<br>on Windows (or ever!). By writing a simple web-server in
<br>POE<<a href="http://search.cpan.org/search?query=poe&mode=all">http://search.cpan.org/search?query=poe&mode=all</a>>(a truly trivial<br>task) you'd have a multitasking non-blocking application<br>that could listen and delegate appropriately. Check-out the cookbook at the
<br>project homepage for some ideas: <a href="http://poe.perl.org/">http://poe.perl.org/</a><br><br><br>Good Luck!<br>Montgomery<br><br><br>On 2/8/07, Sam Foster <<a href="mailto:austin.pm@sam-i-am.com">austin.pm@sam-i-am.com
</a>> wrote:<br>><br>> so what is the skinny with fork on windows? No, not ever, yes with some<br>> workarounds, yes with a particular distribution of perl for win32s?<br>><br>> I'm trying to put a web front-end on a build process - that may take a
<br>> while. Ideally my initial request would kick off the build, and later<br>> requests would check on its status and finally pick up the output and<br>> send it or a link to it back to the client.<br>> I'm developing on and will ultimately be deploying to a windows xp box
<br>> with apache and activestate's perl.<br>><br>> So, it would seem that I should fork to kick the process off, send back<br>> a "working..." message as a response and close stdout in the parent
<br>> process.<br>> The child process goes on working, putting output from the build script<br>> into a file.<br>><br>> The client would keep polling every few seconds to check status, and<br>> grab and respond with the build script output, which will finally
<br>> include a link to where the user can download a zip of the output.<br>><br>> This is just for internal usage, and wont get high traffic. Concurrent<br>> requests are possible, but honestly quite unlikely. In fact, depending
<br>> on the load on the server, the build usually finishes inside a minute so<br>> I could probably keep it simple and just sit and wait for the response -<br>> but I'd like to know what my options are. I do need input (config data)
<br>> from the user so I cant just schedule this and run it nightly or<br>> something.<br>><br>> Oh, and this is supposed to be a fun diversion from my real job, so if<br>> I'm trying to make it too complicated that's why :)
<br>> thanks for any thoughts<br>> Sam<br>><br>> _______________________________________________<br>> Austin mailing list<br>> <a href="mailto:Austin@pm.org">Austin@pm.org</a><br>> <a href="http://mail.pm.org/mailman/listinfo/austin">
http://mail.pm.org/mailman/listinfo/austin</a><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://mail.pm.org/pipermail/austin/attachments/20070208/46f84c4e/attachment.htm">
http://mail.pm.org/pipermail/austin/attachments/20070208/46f84c4e/attachment.htm</a><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 08 Feb 2007 20:24:33 -0600<br>From: Sam Foster <<a href="mailto:austin.pm@sam-i-am.com">
austin.pm@sam-i-am.com</a>><br>Subject: Re: APM: fork on windows / long-running process and cgi<br>To: "<a href="http://austin.pm">austin.pm</a>" <<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID: <
<a href="mailto:45CBDB61.2060201@sam-i-am.com">45CBDB61.2060201@sam-i-am.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br><br>><br>> Have you worked with the POE multitasking framework before? I've
<br>> found that it is a useful (and fun!) alternative when I need a<br>> multitasking application on Windows (or ever!). By writing a simple<br>> web-server in POE <<a href="http://search.cpan.org/search?query=poe&mode=all">
http://search.cpan.org/search?query=poe&mode=all</a>><br>> (a truly trivial task) you'd have a multitasking non-blocking<br>> application that could listen and delegate appropriately. Check-out<br>> the cookbook at the project homepage for some ideas:
<a href="http://poe.perl.org/">http://poe.perl.org/</a><br>><br>See, that's what I'm talking about with needlessly over-complicating<br>things :) Ok, I'll bite, been wanting to look at POE for a while now anyhow
<br><br>Sam<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Thu, 8 Feb 2007 23:43:56 -0600<br>From: Taylor Carpenter <<a href="mailto:taylor@codecafe.com">taylor@codecafe.com</a>><br>Subject: Re: APM: fork on windows / long-running process and cgi
<br>To: "<a href="http://austin.pm">austin.pm</a>" <<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID: <<a href="mailto:1060765E-723C-443B-B20F-732EBE02498F@codecafe.com">1060765E-723C-443B-B20F-732EBE02498F@codecafe.com
</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br>An alternative to POE and your normal thoughts on using fork() is to<br>sharing the information about the current build state "outside of the
<br>CGI app". You can have some CGI app start the build based on certain<br>input (startbuild=1 or whatever) then another script (ot it called<br>differently) can check on the build state (checkbuild=1). When the<br>
build is finished instead of showing current status it redirects to a<br>page that shows full status of the build and the link etc.<br><br>You have many options including<br><br> simple text file that you read from
<br> DB (sqlite would be easy)<br> memcache (<a href="http://search.cpan.org/~bradfitz/Cache-Memcached-1.18/">http://search.cpan.org/~bradfitz/Cache-Memcached-1.18/</a> -<br><a href="http://www.danga.com/memcached">
http://www.danga.com/memcached</a>)<br><br>Randal L. Schwartz has an article on watching long running processes<br>through CGI using Cache::Cache and Apache::Session<br><br> <a href="http://www.stonehenge.com/merlyn/LinuxMag/col39.html">
http://www.stonehenge.com/merlyn/LinuxMag/col39.html</a><br><br>You mentioned having config data from the user. You could also<br>create a file in a directory and check that "incoming" directory for<br>the config information. It would remove the file and start the
<br>build. That could be an app that is always running or something<br>setup in Windows scheduler. Another CGI would show the status of any<br>running builds or finished builds. That information can be stored<br>and various ways including those I mentioned previously.
<br><br>On Feb 8, 2007, at 3:37 PM, Sam Foster wrote:<br><br>> so what is the skinny with fork on windows? No, not ever, yes with<br>> some<br>> workarounds, yes with a particular distribution of perl for win32s?
<br>><br>> I'm trying to put a web front-end on a build process - that may take a<br>> while. Ideally my initial request would kick off the build, and later<br>> requests would check on its status and finally pick up the output and
<br>> send it or a link to it back to the client.<br><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 8 Feb 2007 23:56:57 -0600 (CST)<br>From: Tim McDaniel <<a href="mailto:tmcd@panix.com">tmcd@panix.com
</a>><br>Subject: Re: APM: fork on windows / long-running process and cgi<br>Cc: "<a href="http://austin.pm">austin.pm</a>" <<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID: <<a href="mailto:Pine.NEB.4.64.0702082353580.1305@panix3.panix.com">
Pine.NEB.4.64.0702082353580.1305@panix3.panix.com</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br><br>On Feb 8, 2007, at 3:37 PM, Sam Foster wrote:<br>> I'm trying to put a web front-end on a build process - that may take
<br>> a while. Ideally my initial request would kick off the build, and<br>> later requests would check on its status and finally pick up the<br>> output and send it or a link to it back to the client.<br><br>"Micro-optimizations yield micro-results." You will do builds what,
<br>several times a day, and check their statuses a few dozen times a day?<br>Unless fork() simply didn't work (and it does work, in my experience<br>with Cygwin's perl at least), I don't see why you'd bother to avoid
<br>it. Am I missing something?<br><br>Daniel de Lyncoln<br>--<br>Tim McDaniel, <a href="mailto:tmcd@panix.com">tmcd@panix.com</a><br><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 09 Feb 2007 13:21:21 -0600
<br>From: Sam Foster <<a href="mailto:austin.pm@sam-i-am.com">austin.pm@sam-i-am.com</a>><br>Subject: Re: APM: fork on windows / long-running process and cgi<br>To: "<a href="http://austin.pm">austin.pm</a>" <
<a href="mailto:austin@pm.org">austin@pm.org</a>><br>Message-ID: <<a href="mailto:45CCC9B1.4030506@sam-i-am.com">45CCC9B1.4030506@sam-i-am.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br><br>> "Micro-optimizations yield micro-results." You will do builds what,<br>> several times a day, and check their statuses a few dozen times a day?<br>> Unless fork() simply didn't work (and it does work, in my experience
<br>> with Cygwin's perl at least), I don't see why you'd bother to avoid<br>> it. Am I missing something?<br>><br>><br>I had made a first pass at this and ran into problems which seemed to<br>center right around where my script was supposed to be forking. Rather
<br>than bang my head against it I thought I'd check if this is even<br>supposed to work, or what other options there are. Taylor is right<br>though that I really dont need a fork, I just need to kick off the<br>process, hang up with a response (I just close stdout right?) and let a
<br>future request check on the status. I'm already persisting some info<br>about the build to a file so I could add build status in there.<br><br>Tim: all you are missing is that in truth I dont know what I'm doing, so
<br>my uncertainty is not about optimization, more about learning good<br>patterns that will serve me in the future.<br><br>Sam<br><br><br>------------------------------<br><br>_______________________________________________
<br>Austin mailing list<br><a href="mailto:Austin@pm.org">Austin@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/austin">http://mail.pm.org/mailman/listinfo/austin</a><br><br>End of Austin Digest, Vol 44, Issue 3
<br>*************************************<br></blockquote></div><br>