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

[Thilo Kielmann]

and again: back to the list

----- Forwarded message from Andre Merzky <andre at merzky.net> -----

> Date: Sat, 15 Jul 2006 16:22:47 +0200
> From: Andre Merzky <andre at merzky.net>
> To: Thilo Kielmann <kielmann at cs.vu.nl>
> Cc: Andre Merzky <andre at merzky.net>
> Subject: Re: Fwd (andre at merzky.net): Re: [saga-rg] context problem
> 
> 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

----- End forwarded message -----

-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/