Fwd (andre@merzky.net): Re: Fwd (andre@merzky.net): Re: [saga-rg] context problem
and again: back to the list
----- Forwarded message from Andre Merzky
Date: Sat, 15 Jul 2006 16:22:47 +0200 From: Andre Merzky
To: Thilo Kielmann Cc: Andre Merzky Subject: Re: Fwd (andre@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/
OK, let's assume that creation/deletion of SAGA objects is independent of memory management.
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);
What should be the meaning of destroying s and f, while they are still in use? (if it is NOT memory management) Assuming that we still strive for simplicity, I can not really see why it should be easier to destroy objects, esp. if this does not free memory. Do I understand you right that you propose an "advice", with the semantics: saga_*_destroy may or may not destroy the object actually, depending on whether or not it (who???) still uses the object internally? That sounds like semantics that nobody will understand... (And that means what?? A destroy that is not about memory management and that destroys MAYBE???) Isn't it that the special thing is that a task (or async op) is running asynchronously from the piece of code that has created the task? I see three different (and more-or-lee clean) ways of describing (in the language-independent spec) what shall happen to parameters (like s and f) that are shared between these two threads/activities/tasks: 1. when creating a task, all parameter objects are copied to the new task. + the originating task is free to do with its own objects whatever it likes + the newly created task is a self-contained entity w.r.t. its objects - enforced copying means enforced runtime overhead 2. when creating a task, all parameter objects are "handed over" to the new task + no enforced copying overhead + the newly created task is a self-contained entity w.r.t. its objects, as long as the programmer obeys the hand-over and does not modify or destroy the objects in the creating task/thread/activity - the "if" bears the potential for a lot of tricky error conditions, because objects are shared de-facto 3. when creating a task, all parameter objects are passed "by reference" + no enforced copying overhead - all objects are shared, lots of potential error conditions I think the cleanest version would be 1. (As SAGA always assumed that its own overhead does not matter compared to service invocations.) Thilo PS: Is there a third person on the list who dares sharing his/her opinion??? -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
participants (1)
-
Thilo Kielmann