There are a lot of different factors with all these different solutions. I see 3 basic solutions being proposed.
1) exec() a seperate process and have it run in the background, then use IPC to let a refreshed page show the results. 2) same as above, but using fork() instead of exec(). 3) have the web server process itself do the processing, outputting partial results/status at regular intervals. 4) have a fork()ed apache do the processing and directly output data to the client as it goes via the now cloned socket. As I see it: option 4 has no advantage over option 3, you're already running a child Apache process, so why fork() THAT again? Its just extra overhead and I can so no advantage. Option 1 will probably be more memory-efficient than option 2 because presumeably the exec()ed process is going to be only the code needed to do the processing, so smaller than an entire mod_perl enabled apache process footprint. On the other hand, fork() is a lot cheaper in CPU and perhaps virtual memory than exec(), so the truth is 2 may be faster all around than 1, but in any case is probably going to use less CPU and disk. Personally I see 3 as the least complex option, and it should be just as efficient as 2 and more efficient than 4, so really it seems like a choice between options 1 and 3. As for the method of IPC you use, pick your poison, there are dozens of possibilities... On Monday 28 October 2002 09:52 am, J�rg Walter wrote: > On Sunday 27 October 2002 03:06, Matthew Smith wrote: > > Anyone ever done a background process in XSP? I want to display a > > progress update or something while my user is waiting for their form > > data to be processed. - e.g. I have a button that generates a gzipped > > HTML rendering of my website for uploading to a non AxKit server. How > > would I know that my background process has finished and what the > > results were? > > > > One approach is to fork-exec and put the PID of the forked process into > > the session object. The XSP page could then have a refresh meta tag set > > to a few seconds and check the PID each time it loads until the process > > is finished. It could also check a log file or tmp filename based on > > the PID of the forked process. > > I'd use this variant. It is technically the simplest one. Fast to > implement, reasonable in performance/features. Note that you can replace a > signalling file with an appropriate database table entry. (Not that I would > use that, but for those rdbsomaniacs out there it's possible.) > > > In another approach, the forked process could somehow get hold of the > > session object and put the results there as well as indicating that it > > has not finished yet - maybe use a watchdog counter to detect if it > > crashed. > > This one may work, too, but you get the added overhead of session > file/database/whatever locking. Or, if you don't get locking right, it > might even trash your session records every once in a while. Given the only > advantage is some less files on your hard disk, I think it's not worth. > > > Perhaps there are more elegant ways? > > Well, the truely elegant way would be the following: > > Write a pure mod_perl handler. We need full control. > Create a pipe, fork and do your task. You may work directly from there on > if you like, exec() is not required. In the child, regularly write some > progress information to the pipe. At the end, write result information. > What you write is your thing, just make sure you can read and parse it in > the parent process. > In the parent process, directly send some HTML to start a page. Depending > on your site design, this can be the regular site design, but make sure the > browser is now at the "content" area (where the progress should show), and > _not_ within a table (otherwise some browsers will not render it > immediately). Enter a loop that read from the pipe and prints some text to > the browser each time a new message comes in. When the child is done, print > some HTML to finish the page. > One important thing to watch is that you absolutely must send "something" > to the browser once a minute, otherwise apache itself or intervening > proxies or even the browser may consider the connection dead and close it. > Also, make sure to set the usual "don't cache me" headers in the response. > By the way, this works per CGI as well, at least with Apache 1. I've heard > Apache 2 does some buffering, so that would fail. > > This is far more complex to implment with little gain - it might even hog > your server's memory resources much more than the simple solution above. So > you might still consider the simple variant. -- Tod G. Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
