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

[Thilo 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/