On Sat, May 03, 2008 at 06:11:06PM -0700, Wicked wrote:
> I'm currently writing a robust unit-of-work (don't want to use the
> 'task' in another meaning here) execution scheduler daemon, which
> takes some units-of-work from the db and passes them to invoked
> workers. The workers are currently supposed to be just CLI scripts
> that are run by a 'background' system('... &') call.It sounds like a task is exactly what you need. You execute any task from your unit-of-work as: $task = new WhateverTask($dispatcher, new sfFormatter); $task->run($arguments, $options); With tasks, you don't need to do any CLI calls. Carl > From the point of view of speed, tasks seem killing for me. It takes > about 4 seconds for log:clear to complete on my PC (athl xp 3200+ / > 1gb ram / hdd sata 500gb) which makes the symfony tasks unusable as > workers in my case. The batch scripts would fit much more because they > tend to not perform a ton of work that tasks usually do. Also batch > scripts can use full-scale caching, etc. But in the UPGRADE doc in the > symfony 1.1 it's said that the batch scripts are deprecated now. So > it's a dilemma for me :) > > So what am I supposed to do? I don't believe I'll be able to to > optimize the tasks sub-framework in such major extent. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
