[MTOS-dev] Background Task Change

Byrne Reese byrne at sixapart.com
Fri Feb 8 12:39:35 PST 2008


I have thought a lot about this too, and it seems that we have been thinking
around the same lines.

Tell me, does this also sound similar to what you just proposed:

1) for each request init a queue of jobs for the span of the request
2) at the end of the request life cycle:
   - if TheSchwartz is turned on, then commit the jobs to the queue
     for processing in the background
   - else process the jobs inline with the request
     3) use a modal dialog or a second screen to show the system working on
        queued requests

Does that make sense?

In other words, standardize upon ONE job queuing system. That way they can
just as easily be processed in the background as the can in the foreground.

On 2/8/08 12:02 PM, "Reed A. Cartwright" <reed at scit.us> wrote:

> With the discussion on pronet about background tasks I have a proposal
> to make to change the background task system.
> 
> Instead of forking to do background tasks, MT should process them after
> the page is finished being served.  This is the technique that I use in
> MT-Dispatch to run the the Schwartz (publishing queue) in the worker
> threads.
> 
> The basic pseudo code is as follows:
> 
> 1. open connection
> 2. run app, queuing any bg tasks
> 3. send page to user
> 4. close connection (streams)
> 5. go through bg queues
> 6. terminate if cgi; server next request if fcgi
> 
> I think this would improve task processing and even become more portable
> since MTOS wouldn't need to use fork.



More information about the MTOS-dev mailing list