On 06/18/10 02:23 AM, Darren Kenny wrote:
Hi Karen,
Thanks for writing this up, some comments in-line... :)
On 06/18/10 12:34 AM, Karen Tung wrote:
Here's a summary of discussions we had this morning
on the Install Execution Engine design.
1) Application's usage of InstallEngine.execute_checkpoints() and threading:
- If an application calls execute_checkpoints() with a callback function,
execute_checkpoints() will return after all checkpoints are instantiated.
When the thread executing checkpoints is completed, the callback function
provided by the application will be called.
This sounds good, but I'd like to be sure that when looking at designing the
callback mechanism, that the method being called will be provided with
suitable status information - nothing much, just enough to know if it's a
success, failure, partial failure - so that it can do the correct thing.
I see two ways that this call back would be called:
1) From the Checkpoint-Execution-Thread - i.e. thread handling the running of
checkpoints in sequence, on completion/failure, would call the callback.
2) The Engine calls the callback, after the Engine has been notified through
some "internal" mechanism, that the Checkpoint-Execution-Thread has
completed.
I don't have a preference for which is best, but which ever is chosen, then I
think that it will be important for document whether the callback will be
called from another thread (as in case 1), or from the same thread that the
Engine was called from (case 2).
I believe case (1) makes it simpler to implement the non-blocking behavior.
You're correct that the function signature for the callback needs to be
well-defined. Would a simple boolean indicating whether there were
exceptions or not be sufficient? The implementor of the callback could
then know whether of not it needs to examine the list of exceptions that
occurred during execution or not.
[...]
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.
Is it really necessary to store the object? Would a str(object) not suffice?
I'm mainly wondering if it's worth the effort to add support for objects to
the API, when I really don't think anyone needs that much information.
When it comes to exception handling, you can rarely have "too much"
information - but it's VERY easy to squelch out / accidentally hide
valuable information. It's better to let the app determine what to do
with the exception; the engine simply needs to provide a way to pass
that information from the "checkpoint execution" thread to the "main
application" thread.
- Keith
6) After a checkpoint completes successfully, the engine will always send
a progress update to the logger on the overall percentage complete. This
allows accurate progress to be reported even if a checkpoint does not
report intermediate progress.
Agreed.
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
