[saga-rg] Re: SAGA, object states, and concurrency

[Andre Merzky]

Quoting [Thilo Kielmann] (Aug 01 2006):
> > Our favourite bulk file copy code snippet would, for
> > example, cease to work:
> > 
> > -----------------------------------------------
> >   saga::task_container tc;
> > 
> >   for (i = 1; i < 1000; i++)
> >   {
> >     saga::file f (url[i]);
> >     saga::task t = f.copy <saga::Task> ("/tmp/");
> >     tc.add (t);
> >   }
> >   
> >   tc.run ();
> >   tc.wait ();
> > -----------------------------------------------
> > 
> > Its not only the file object which goes out of scope here,
> > its also the task!  
> 
> Indeed, this code is broken. It might artificially be made to work by all the
> fancies that you guys have put into the implementation.
>
> In proper code, objects would be created on the heap (with new).
> You better do that anyway as you don't know how big your stack is and how big
> the objects are that some 3rd-party library creates. (Esp. if you have multiple
> threads, you cannot assume stacks to grow infinitely.)

Ok, assume we define the async methods to return pointers to
tasks, not task instances (you cannnot use 'new()' to create
a task):

----------------------------------------------
   saga::task_container tc;

   for (i = 1; i < 1000; i++)
   {
     saga::file * f = new saga::file (url[i]);
     saga::task * t = f->copy <saga::Task> ("/tmp/");
     tc.add (t);
   }
   
   tc.run ();
   tc.wait ();
----------------------------------------------

The the code is valid, but, again the user needs to keep
track of the instances as they are used _internally_ in
saga.

> Yes, with C++ you have to do life cycle management of object references.

Of course - but that does not mean you cannot do it IN the
library.  For example QT, which is regarded as a poster
child and easy-to-use C++ library, object life time is
managed in the libqt, not in the application (the
application CAN manage the lifetime explicitely though).  WT
uses following mechanisms:

  - shared pointer (QPointer)
  - special slots (delate_later, destroyed) to signal
    internal object destruction
  - object dependencies (if parent gets destroyed, children
    get destroyed).

There is no reason to put that burdon to application level.

I don't see that as an language issue BTW - I know that can
be done in C (hence in also in Fortran bindings), Python and
Perl, and I am rather positive for Java, too.


> I know, by keeping SAGA out of the memory management
> business, the price for this clarity is manual destroying
> of objects.

I think we differ in what clarity means.  You propose a
clear definition, and simple rules.  I would argue that
clear and simple application code is more important.

> But: we should stop arguing over artificial examples that
> are only designed for proving a certain argument.

I'd be happy to see code proving the opposite :-)  But
really, all what should matter is the end is what the
application programmer will see, and use, and that is code.
It does not help us to define simple rules etc, if the
resulting SAGA code is cumbersome to use...

> Sessions are by definition rather static; in a real
> application I can not see a session to be destroyed before
> the end of the program anyway.

Maybe.  But that is definitely note the case for tasks and
other object dependencies.


> > All that is simple to do in the SAGA implementation, which
> > _knows_ where it is inherited, and which will do ref
> > counting anyway...
> 
> No way. SAGA needs to stay away from object lifecycle management.

Can you explain why?


> > Again, I think your proposal is simple and it works, so its
> > an valid option -- but IMHO it makes programming SAGA
> > applications an ugly business.
> 
> Yes, in less advanced languages there is some price to pay.
> But there is no single reason to spoil the language-independent 
> spec, just because C++ doesn't have proper memory management.

No, thats not a language issue - see above.

Andre.

-- 
"So much time, so little to do..."  -- Garfield