[SAGA-RG] Some more comments on the SAGA specs.

[Andre Merzky]

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 at 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.