[dev] [commits] Horde branch develop updated. 1e74759a311a275c4a8bf536bec415bd62c37df7

Chuck Hagenbuch chuck at horde.org
Tue Nov 22 14:24:42 UTC 2011


IMO tasks need to be as independent as possible. Prefs shouldn't be accessed, neither should session, etc. And they should probably create registry (or the runner should) if they need it. So __destruct still seems like the right answer here. 


-chuck

On Nov 17, 2011, at 5:00 PM, Michael J Rubinsky <mrubinsk at horde.org> wrote:

> 
> Quoting Chuck Hagenbuch <chuck at horde.org>:
> 
>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>> 
>>>   This now seems to work only when using the Ajax uploader. When using the
>>>   traditional uploader, the browser is directed back to the gallery before the
>>>   task is finished running, and this kills the request....
>> 
>> Maybe we need something like ignore_user_abort() in the shutdown runner? As well as session_write_close() of course, which I don't think we have yet.
> 
> Yeah, I got that far regarding ignore_user_abort(). There was a larger problem though, in that triggering the task runner from __destruct() gives us absolutely no control over when it is run in relation to other objects being gc'd. For instance, I was running into the problem of things like $registry and $prefs not being available during task execution.
> 
> I changed the code to register the tasks to run with a register_shutdown_function. This ensures all (most?) needed objects are still around since this is one of the first shutdown_functions registered. The drawback to this is that the browser will still spin during execution.  I've tried a number of ways of killing the connection like e.g., sending the connection: close header, flushing the buffer etc.., but all of them have resulted in communication errors in the browser. I don't think we can kill the session from the shutdown_function either, as we have no way of knowing if another shutdown function in the chain will want to do something with it.
> 
> At least now all the tasks are run, with most of the Horde environment available for the tasks...
> 
> -- 
> mike
> 
> The Horde Project (www.horde.org)
> mrubinsk at horde.org
> 
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org


More information about the dev mailing list