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