[SAGA-RG] Final call: task model...

[Hartmut Kaiser]

Andre, 

> The proposal is as follows:  the original task model resulted 
> in the following code (C++):
> 
> ------------------------------------------------------------
>   std::size_t  len_in   = 11;
>   std::char    data[12] = "hello world";
>   std::ssize_t len_out;
> 
>   saga::file f (url);
> 
>   saga::task t = f.read <saga::task::Async> (buffer (data, 
> len_in), &len_out);
> 
> 
>   // some time later, in a different code section
> 
> 
>   t.wait ();
>   std::cout << "read " << len_out << " bytes" << std::endl;
> ------------------------------------------------------------
> 
> That would change to:
> 
> ------------------------------------------------------------
>   std::size_t  len_in   = 11;
>   std::char    data[12] = "hello world";
> 
>   saga::file f (url);
> 
>   saga::task t = f.read <saga::task::Async> (buffer (data, len_in));
> 
> 
>   // some time later, in a different code section
> 
> 
>   std::ssize_t len_out = t.get_result <std::ssize_t> ();
> 
>   std::cout << "read " << len_out << " bytes" << std::endl;
> ------------------------------------------------------------
> 
> 
>  change:
>   - task gets a templatized member function get_result(),
>     which returns the return value of the async funtion
>     after the task gets completed.  Calling get_result()
>     implies a wait().
> 
>  PROs:
>   - no need to carry the return value from task creation to
>     where it is getting used.
>   - no possibility to access the uninitialized return value
>   - sync and async calls have _exactly_ the same signature
>     now, and only differ in their return values.
> 
>  CON: 
>   - adding templates for member functions in application
>     space.

I all agree to change it this way, even if I'm a bit hesitant to do so,
because it involves an almost complete rewrite of our existing C++ SAGA
implementation (at least as far as tasks are involved) and breaks backwards
compatibility. Additionally I find it - let's say amusing - that after long
discussions around templates, which have been furiously rejected mainly by
Java people, we are now back to templates. Is this because our well
respected colleagues using Java suddenly discovered to have templates
available in newer versions of the language? SCR. :-P

Leaves us with the question if this is implementable in other languages as
well, such as C, FORTRAN or scripting languages. I'm not sure if that's
possible. Especially scripting languages often rely on runtime polymorphism,
not compile time polymorphism. Wouldn't it be better to leave the templated
interface as an implementation detail and just to require to store the
result inside the task? As I said - I'm not sure.

> As a side note: earlier in the evolution of the spec, we 
> dropped the following mechanism:
> 
> ------------------------------------------------------------
>   saga::task t = f.seek <saga::task::Async> (where, whence));
> 
>   // some time later, in a different code section
> 
>   t.wait();
>   saga::file f2 = (saga::file) t.get_object ();
> 
>   f2.read (...);
> ------------------------------------------------------------
> 
> which allowed to get the originall calling object back from a 
> task, and thus eliminating the need for the application to 
> keep track of task/object relations.  
> 
> That was removed because of the cast implied, and a UUID was 
> added instead to simplify the application level book keeping.
> 
> However, we could, with the same mechanism, add a type safe 
> get_object again, with no penalty:
> 
> ------------------------------------------------------------
>   saga::task t = f.seek <saga::task::Async> (where, whence));
> 
>   // some time later, in a different code section
> 
>   t.wait();
>   saga::file f2 = t.get_object <saga::file> ();
> 
>   f2.read (...);
> ------------------------------------------------------------
> 
> which would eliminate (or at least minimize) the need for 
> application level book keeping.

Again, I agree with this, but same comments apply as above. Templates should
be left as an implementation detail. Furthermore, even in C++, this can be
written as:

------------------------------------------------------------
  saga::task t = f.seek <saga::task::Async> (where, whence));

  // some time later, in a different code section

  t.wait();
  saga::file f2(t.get_object());

  f2.read (...);
------------------------------------------------------------

where the constructor takes the saga::object directly, checking for matching
types and throwing an exception if not. The disadvantage is that we move the
check from compile time to the run time, which is undesireable. OTOH, the
get_object<saga::file>() above does enforce the type matching at runtime
only as well. So well, we wouldn't loose anything here.
The advantage is simplicity and a similar interface if compared with other
languages.

Regards Hartmut