Fwd (andre at merzky.net): Re: [saga-rg] context problem

[Andre Merzky]

Let me re-formulate the example:

  saga::session *s = new saga::session ();
  saga::file    *f = new saga::file    (s, url);

  saga::task     t = f->copy <saga::task::Task> (target);

  delete (s);
  delete (f);

  t.run ();

That is the C++ version with explicit memory management, and
boils down to the same problem, right?  Now, that looks
similar in Java I assume, but I know for sure its the same
for Python, Perl and C:

  saga_task* t;

  saga_session s = saga_session_create ();
  saga_file    f = saga_file_create (s, url);
  
  saga_task    t = saga_file_copy_task (target);

  saga_session_destroy (s);
  saga_file_destroy    (f);

  saga_task_run (t);
  

It can be implemented, easily, in both ways: to be valid,
and to be invalid.  In the C example, assume that s, f and t
are actually integers, which act as handles to the internal
memory.  If that internal memory is freed or not on
..._destroy is a SAGA policy, not a C memory management
issue.  If that code is valid or not is not a C/C++
question, it is a question the language independent SAGA
spec must address.

> "keeping objects alive" is a C++ thing.

No, I disagree. I think you mean the memory management: that
is an C++ thing here because it is an C++ example.

If the user can expect the above code to work or not is not
a C++ question, it needs to be addressed in the language
independent spec.

Well, and getting back to the original point: I would
actually argue for that code to be valid, as it allows to
pass task handles around, w/o burdening the application
programmer to pass the objects, session and contexts around
as well.

Cheers, Andre.



Quoting [Thilo Kielmann] (Jul 15 2006):
> 
> > > Right, we agree. If there are more/other contexts that might still be OK.
> > > IMHO, if the programmer is removing a context that is still needed, that is
> > > a mistake that might lead to an error.
> > 
> > Yes, we could do that, agree.  However, we are already going
> > a different route with sessions and tasks:
> > 
> >   --------------------------------------------------------
> >   saga::task t;
> > 
> >   {
> >     saga::session s;
> >     saga::file    f (s, url);
> > 
> >     t = f.copy <saga::task::Task> (target);
> >   }
> > 
> >   t.run ();
> >   // session and file object are gone here - however, the
> >   // task still lives, and keeps the session and object
> >   // resources alive.  At least some state must be
> >   // maintained internally
> >   --------------------------------------------------------
> > 
> > As usual, that example is in C++, but the problem is
> > independent of the language.
> 
> :-)
> 
> > 
> > I think that this is the same problem really as with the
> > context.  I think we should solve the the same way.
> 
> Absolutely.
> 
> > The problem really is, I think, that the above example is
> > the dominating one.  Tasks, as they represent async ops, 
> > are bound to get passed around through different scopes, 
> > and it would be burdensome to expect the programmer to 
> > keep all associated objects, sessions and contexts etc.
> > alive.
> 
> "keeping objects alive" is a C++ thing.
> This means, both for contexts and sessions (and all other similar objects),
> that the C++ language binding has to define a "object lifecycle policy" that
> clearly states who (which class, e.g. user) is in charge of creating and
> destroying objects. Part of this policy is to say whether or not objects
> are copied when passed to another object, or whether they are used "by
> reference".
> 
> So far, C++. And now back to SAGA semantics.
> 
> What I can see in the code example above is that there is no problem for the
> SAGA operations. It is 100% a C++ problem:
> a) if session and file are passed to the task by reference, then the above
>    code is simply incorrect
> b) if session and file are copied to the task, this code is fine
> 
> 
> Cheers,
> 
> 
> Thilo
-- 
"So much time, so little to do..."  -- Garfield