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

[Thilo Kielmann]

[[ just putting the thread back onto the list before answering ]] 

Thilo

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

> Date: Fri, 14 Jul 2006 19:53:07 +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: [saga-rg] context problem
> 
> The problem is not really C++ here I think.  The code
> snippet below is semantically challenging in any
> language, and we need to define that semantic in the spec.
> 
> The implementation in C++ is another issue, and simple :-)
> 
> Making a copy of the context does not help.  The problem, as
> said, is that the 'remove_context' can get called before or
> while that context is used, and that needs to have a well
> defined semantic in the (lang independent) spec.
> 
> Having it a user level error is an option.  Well, not really
> an error, but what you say (I think) is that the later
> operations on that object cannot use the Globus context -
> right?
> 
> Cheers, Andre.
> 
> 
> Quoting [Thilo Kielmann] (Jul 14 2006):
> > 
> > Hi,
> > 
> > I think this issue "nicely" confuses SAGA semantics and C++ memory management.
> > 
> > From a SAGA viewpoint I would say: it is an error (mistake by the user)
> > to remove a context from a session if this context is still to be used,
> > e.g. with the task object in the example.
> > 
> > Issues with C++ objects going out of scope when they are still needed
> > have to be resolved within a C++ language binding.
> > for example: s.add_context(c) could make a copy of the c object.
> > Or: the add_context operation prescribes that the c object it got will
> > not be destroyed elsewhere (and then the desctructor of s is in charge of
> > freeing this memory)
> > 
> > 
> > Having "remove context advisory" solves neither problem.
> > As appliation programmer, I would be confused...
> > 
> > 
> > Thilo
> > 
> > On Fri, Jul 14, 2006 at 04:46:33PM +0200, Andre Merzky wrote:
> > > Date: Fri, 14 Jul 2006 16:46:33 +0200
> > > From: Andre Merzky <andre at merzky.net>
> > > To: SAGA RG <saga-rg at ggf.org>
> > > Subject: [saga-rg] context problem
> > > 
> > > Hi folx, 
> > > 
> > > I realised that we are running into some problems with our
> > > current session and context handling.  For example:
> > > 
> > >   
> > >   ------------------------------------------------------------
> > >   saga::task    t;
> > >   saga::session s;
> > > 
> > >   {
> > >     saga::context c (saga::context::GSI);
> > > 
> > >     s.add_context (c);
> > > 
> > >     saga::file f (s, url);
> > > 
> > >     t = f.copy <saga::task::Task> (target);
> > > 
> > >     s.remove_context (c);
> > >   }
> > >   // as it leaves the scope, the gsi context gets destroyed.
> > > 
> > >   t.run (); 
> > >   // the task can not use the GSI context, although the file
> > >   // object and the copy task have been created in a session
> > >   // with a valid GSI context.
> > >   ------------------------------------------------------------
> > > 
> > > 
> > > The problem really is that, as a context gets removed, no
> > > assumption is made about the fact that the session might
> > > have active objects which are currently using that context.
> > > 
> > > The example above is harmless - image a context getting
> > > removed between two subsequent read calls, or while a task
> > > is _running_.
> > > 
> > > 
> > > I would propose to change the semantics of remove_context to
> > > be advisory, i.e. to allow existing objects and tasks to
> > > continue to use the context if (and only if) it was already
> > > used by them before.  The session SHOULD free context
> > > related resources as soon as no object uses it anymore.
> > > list_context() MUST NOT list the removed context anymore.
> > > 
> > > We have similar mechanisms in place to keep sessions alive
> > > if they are needed by objects, and to keep objects alive if
> > > they are needed by tasks.  So that would be a somewhat
> > > coherent approach.
> > > 
> > > The downside of course is that, at one more place, resource
> > > deallocation is out of sync with the appearent object
> > > destruction.  
> > > 
> > > Any opinion?
> > > 
> > > Cheers, Andre.
> > > 
> > > 
> > > 
> > > -- 
> > > "So much time, so little to do..."  -- Garfield
> -- 
> "So much time, so little to do..."  -- Garfield

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

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