[saga-rg] Task model...

[Tom Goodale]

My vote is for 4a1. (Which was option D in our original discussion I 
believe.)

Cheers,

Tom

On Thu, 3 Nov 2005, Andre Merzky wrote:

>
> Hi John, Thilo, Group,
>
> Hartmut and I would like to argue about the C++ bindings.
> We would like to come to an agreement soon, as our
> implementation is dealing with the async part right now.
>
> As reminder:
>
> ---------------------------------------------------------------------
> Example 4a: more versions in C++
>
> 4a1:               d.mkdir         ("test/");
>                   d.mkdir_sync    ("test/"); // same
>  saga::task t_1 = d.mkdir_async   ("test/");
>  saga::task t_2 = d.mkdir_task    ("test/");
>
> 4a2:               d.mkdir         ("test/");
>                   d.sync .mkdir   ("test/"); // same
>  saga::task t_1 = d.async.mkdir   ("test/");
>  saga::task t_2 = d.task .mkdir   ("test/");
>
> 4a3:               d.mkdir         ("test/");
>                   d.mkdir <sync>  ("test/"); // same
>  saga::task t_1 = d.mkdir <async> ("test/");
>  saga::task t_2 = d.mkdir <task>  ("test/");
>  ---------------------------------------------------------------------
>
>
> Quoting [John Shalf] (Nov 02 2005):
>>
>>>   Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!)
>>
>> I prefer 4a1 because it is more readable and the implementation would
>> be quite straightforward.
>
> You favour 4a1.  We think that implementation is very straight
> forward for all three versions.  Readability seems not much
> different to me, and might largely be a matter of taste.
>
>
>> It is also a familiar paradigm for any MPI
>> programmers and anyone who has played with various proprietary Async
>> I/O implementations. (its a very familiar and conventional approach)
>
> Well, these are C-API's.  Is there a C++ binding for MPI,
> and does it look the same?
>
>
>> I kind of like 4a2 as well from the standpoint of a C++ programmer
>> (even with Andre's syntax corrections).  However, the resulting
>> bindings will not be very consistent with the approach we would take
>> for Fortran or C bindings (eg. those would likely look more like
>> 4a1).
>
> But, well, that is the idea of the language binding!  I agree
> that C and Fortran would look more like 4a1, of course.  But that
> is no reason that C++ should look like that as well, or Java,
> Perl etc.
>
>
>> It is not really much more readable than 4a1.  Therefore, I'm
>> uncertain if it is worth fragmenting our approach to bindings in
>> different languages when there is not a clear benefit in terms of
>> readability or implementation complexity.
>
> I think that 4a2/4a3 actually allow nicer implementations, as it
> allows to have the different async parts somewhat separate from
> the sync parts.  We think its nicer :-)
>
>
>> I do a lot of C++ programming, but I find the 4a3 option a bit
>> obscure both in terms of readability and any advantages it might
>> confer in terms of implementation.
>
> Hehe - I thought the same :-)  Hartmut likes that version very
> much.  To me it appealed after pondering over it for a couple of
> days.  Now I think it is cute, and quite expressive.
>
>
>> It would certainly be easier to
>> create multi-language bindings for a single code base if we stick
>> with something more conventional like 4a1.
>
> I think that C and Fortran bindings for this part are straight
> forward anyway, there is no need to reflect that in C++...
>
>
>> Each approach is equally readable to me (less so for 4a3).  I'm
>> certainly open to any additional information on how the 4a2 and 4a3
>> approaches could simplify implementation.
>
> The main point really is that the object itself has only the sync
> method calls, and the async calls can be put into separate
> header/sources easily, and build (by default) on top of the sync
> calls.  Of course, you can do that with all three versions, but
> its not as obvious in 4a1.
>
>
>> If the other approaches
>> can offer some implementation benefits, then maybe I'd give them
>> extra consideration, but otherwise, I would prefer a more
>> conventional approach like 4a1.
>
> I would  vote for 4a2 or 4a3 (in that order), but 4a1 would be ok
> if the majority likes that most, of course.  Basically its
> a matter of taste I think.  I am happy that the general point
> seems accaptable to all so far: having sync, async, and task
> versions of the calls, w/o explicit task factory.
>
>> The only implementation I'm outright
>> against is the 4b example.
>
> Good! :-)
>
> Thanks, Andre.
>
>
>> -john
>
>
>
>