Hi Dermot,
On 06/18/10 06:18 AM, Dermot McCluskey wrote:
2) Canceling a checkpoint
- It's the application's responsibility to setup a signal handler to
process
signals such as control-c.
- When the engine receives a cancel_checkpoints() request, it will
call the cancel() function of the checkpoint that's executing.
- The default implementation for the AbstractCheckpoint.cancel()
function
will be to set a threading.Event variable.
Checkpoints that do not overwrite the default cancel() implementation
should
check the value of this variable using the is_set() function, and
perform the necessary cleanup and exit.
- Checkpoints that do not want to use the default cancel()
implementation can overwrite with it's
own implementation when they subclass the AbstractCheckpoint object.
So, the reasons for overriding cancel() would be if:
- the Checkpoint wants to get notification immediately if the app
requests a
cancel, rather than just waiting for the next time that the
Checkpoint can
test the threading.Event variable, OR
If they really want to be notified immediately, they can always use
thread.Event.wait() on the variable. That's one way to do it, if they
really want to.
Of course, they can also override with another implementation for cancel().
- the Checkpoint's implementation makes it unsuitable to regularly
test the
threading.Event variable (eg it executes a sub-command that takes up
most
of the time)
Is that right?
It's each checkpoint developer's choice to use the default or override
as they see fit. I think the 2nd case you above is probably a more
common use case
for overriding the default cancel() implementation.
4) AbstractCheckpoint.get_progress_estimate()
- This function will return the number of seconds it takes to execute
the checkpoint
in seconds as measured by the wall-clock, on a standardized machine.
In ManifestParser, I expect execute() to typically take less than 0.2
seconds. In
this case, should get_progress_estimate() return 0 or 1?
I would recommend to aways round up. In fact, the engine will always
round up to
the next integer if a decimal is provided as the weight.
As Dave mentioned in his reply, a checkpoint should return at least 1
second for the
progress estimate.
5) Keith's question about using Error Service module (errsvc) for
storing
exceptions raised by the checkpoints, instead of storing the exceptions
as a list.
- the Error Service module is suitable and can be used with some
modifications.
- The ErrorInfo object can be used to store the exception.
The mod_id in the ErrorInfo object can be used for storing the name
of the checkpoint
that raised the exception.
- As currently implemented, ErrorInfo object only accepts
"integer" and "string" as the error data type. It needs to be
modified to
accept an "object", which will be used for storing the exception raised
by the checkpoint.
Can you log a bug against the errsvc for this?
I just filed:
*Bug 16322* <https://defect.opensolaris.org/bz/show_bug.cgi?id=16322> -
errsvc should support object as a valid error data type
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
