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

[Andre Merzky]

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 <kielmann at cs.vu.nl>
> > To: saga-rg at ggf.org
> > Subject: Re: Fwd (andre at merzky.net): Re: Fwd (andre at 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