[[ just putting the thread back onto the list before answering ]] Thilo ----- Forwarded message from Andre Merzky -----

Date: Fri, 14 Jul 2006 19:53:07 +0200 From: Andre Merzky To: Thilo Kielmann Cc: Andre Merzky 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 To: SAGA RG 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/