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

Taylor Carpenter taylor at codecafe.com
Thu Feb 8 21:43:56 PST 2007


An alternative to POE and your normal thoughts on using fork() is to  
sharing the information about the current build state "outside of the  
CGI app".  You can have some CGI app start the build based on certain  
input (startbuild=1 or whatever) then another script (ot it called  
differently) can check on the build state (checkbuild=1).  When the  
build is finished instead of showing current status it redirects to a  
page that shows full status of the build and the link etc.

You have many options including

	simple text file that you read from
	DB (sqlite would be easy)
	memcache (http://search.cpan.org/~bradfitz/Cache-Memcached-1.18/ -  
http://www.danga.com/memcached)

Randal L. Schwartz has an article on watching long running processes  
through CGI using Cache::Cache and Apache::Session

	http://www.stonehenge.com/merlyn/LinuxMag/col39.html

You mentioned having config data from the user.  You could also  
create a file in a directory and check that "incoming" directory for  
the config information.  It would remove the file and start the  
build.  That could be an app that is always running or something  
setup in Windows scheduler.  Another CGI would show the status of any  
running builds or finished builds.  That information can be stored  
and various ways including those I mentioned previously.

On Feb 8, 2007, at 3:37 PM, Sam Foster 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.


More information about the Austin mailing list