Hi Ceriel, Quoting [Ceriel Jacobs] (Feb 17 2010):
Hi,
I posted the message below earlier to this list, but got no reactions, and the bugs mentioned have not been fixed, so I think a repost is in order.
sorry for the late answer - I think I missed your earlier mail...
Here is the message:
I have some more remarks/questions about the new Saga specifications, this time about the task package. Here they are, in random order:
Bugs:
task.wait() in the details does not specify a default value for the timeout.
Thanks, now fixed in CVS
PreCond on task.cancel(): sais that task is in 'Running' state, but the Notes say that it can also be in a final state, in which case the cancel has no effect.
The notes are correct - I fexed the Pre and Post condition. Rationale is to avoid race conditions like in if ( task.get_state () == saga::task::Running ) { task.cancel (); // task may be final here already }
Why does task_container.remove() return the removed task? It is already specified as parameter.
Correct, but this is already fixed in CVS: remove is now of void type, and returns nothing.
PostCond on task_container.run(): sais that all tasks in the container are in 'Running' state, but I guess the only thing you can be sure of is that the state is not 'New', like with task.run().
Agree.
PostCond on task_container.cancel(): sais that if no timeout occurs all tasks in the container are in 'Canceled' state. But the tasks can be in another final state as well.
Agree - same as on cancel earlier.
Debatable issues:
task_container: what is the difference between list_tasks() and get_tasks()? list_tasks() originally returned the cookies. Should it now return a list of object ids? Or should the method just be removed alltogether?
Uh, right. Yes, I think it should be removed now.
I am not sure that it is a good idea to have get_result() call rethrow(). How do I now make a distinction between an exception coming from the get_result() call itself and an exception from the task? I guess that in the exception handler I can check the state of the task, but that does not give you a definite answer: if the state is "FAILED", the exception can still come from get_result() itself, can it not? Why not leave it to the user to call rethrow() if he/she wants, and as it was before?
The rationale was to allow to use a task as a future, like in the following code: saga::task t = rpc.call <saga::task::Async> (); a = do + something + important + here; b = which - takes - a - long - time; // implicit synchronization final_result = a + b + t.get_result <int> (); If get_result() does not call rethrow(), one needs to always perform a wait, and a state check at the point of usage, like: saga::task t = rpc.call <saga::task::Async> (); a = do + something + important + here; b = which - takes - a - long - time; t.wait (); // explicit synchronization if ( t.get_state () == saga::task::Failed ) { t.rethrow (); } else { final_result = a + b + t.get_result <int> (); } Also, I don't see any prevalent cases where get_result() would throw additional exceptions which would not come from the task itself (i.e. which would not be raised on rethrow() anyway). The only case is local resource shortage, but we neglect that issue in many other places (and rightly so I think). Cheers, Andre.
Cheers, Ceriel -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
In addition, there is a small glitch in the PreCond of the task.get_result() call: it sais that the task should not be in Failed state, which is strange, considering that it can be in Failed state after the (implied) wait(). What I said above about get_result() is probably a misunderstanding on my part, but it still is unclear if any exception thrown by get_result() comes from the task itself or from the get_result() method. For instance, if the task state is Failed, and get_result() throws NotImplemented, is that because get_result() is not implemented or because the method it executed is not implemented?
Cheers, Ceriel -- Nothing is ever easy.