On Mon, 2013-04-29 at 20:05 +0200, Pavel Březina wrote:
On 04/29/2013 07:52 PM, Simo Sorce wrote:
> On Mon, 2013-04-29 at 11:54 +0200, Pavel Březina wrote:
>> Ah, yes. If the request returns ERR_STOP_PERIODIC_TASK, the task will
>> completely destroyed, otherwise it will reschedule: when EOK, it will
>> fire the request in last-execution-time + period, otherwise now +
> Wouldn't it be simpler to simply stop on any error, and reschedule only
> when EOK is returned ?
> This way the task can bubble up the error all the wya w/o having to mask
> it to a ERR_STOP_PERIODIC_TASK error at the very end.
No, you want to terminate the periodic task only on fatal error which
you can't recover from. E.g. you want to reschedule the task when you
can't connect to LDAP, but terminate it if LDAP server doesn't support
If you return ERR_STOP_PERIODIC_TASK, the task will not be rescheduled.
It will be rescheduled on any other error code and logged as appropriate.
I guess the point here is what you want to do by default.
In either case you need to check and remap error codes before returning.
If you define ERR_STOP_PERIODIC_TASK, then you want a continue by
default, let's stop only on white listed errors.
If there is a new 'fatal' error you do not catch in whatever function
normally converts to ERR_STOP_PERIODIC_TASK. Then the task will be
The other point is that with ERR_STOP_PERIODIC_TASK, you also have to
log where you map because it won't bubble up.
I can see the advantages as well though, so I do not have a strong
preference at this point, carry on :)
Simo Sorce * Red Hat, Inc * New York