I should have added that I'd prefer 3:

...

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

The error conditions I could think of are: - change state of object while a task is running, hence having the task doing something differently than intended - limited control over resource deallocation The advantages I see: - no copy overhead (but, as you say, that is of no concern really) - simple, clear defined semantics - tasks keep objects they operate on alive - objects keep sessions they live in alive - sessions keep contexts they use alive - sync and asyn operations operate on the same object instance. Either way (1, 2 or 3), we have to have the user of the API thinking while using it - neither is not idiot proof. I think (2) is most problematic, if I understant your 'hand-over' correctly: that would mean you can't use the object again until the task was finished? Cheers, Andre. Quoting [Andre Merzky] (Jul 16 2006):

Hi Thilo,

very good points, and indeed (1) seems cleanest. However, it has its own semantic pitfalls:

saga::file f (url); saga::task t = f.write saga::task::Task ("hello world", ...);

f.seek (100, saga::file::SeekSet);

t.run (); t.wait ();

If on task creation the file object gets copied over, the subsequent seek (sync) and write (async) work on different object copies. In particular, these copies will have different state - seek on one copy will have no effect on where the write will occur. That is the reason why we have the delayed object destruction in the first place: that tasks can share state.

Cheers, Andre.

Quoting [Thilo Kielmann] (Jul 16 2006):

...

Date: Sun, 16 Jul 2006 18:20:50 +0200 From: Thilo Kielmann To: saga-rg@ggf.org Subject: Re: Fwd (andre@merzky.net): Re: Fwd (andre@merzky.net): Re: [saga-rg] context problem

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???

-- "So much time, so little to do..." -- Garfield