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