[saga-rg] Re: SAGA, object states, and concurrency

[Thilo Kielmann]

> Our favourite bulk file copy code snippet would, for
> example, cease to work:
> 
> -----------------------------------------------
>   saga::task_container tc;
> 
>   for (i = 1; i < 1000; i++)
>   {
>     saga::file f (url[i]);
>     saga::task t = f.copy <saga::Task> ("/tmp/");
>     tc.add (t);
>   }
>   
>   tc.run ();
>   tc.wait ();
> -----------------------------------------------
> 
> Its not only the file object which goes out of scope here,
> its also the task!  

Indeed, this code is broken. It might artificially be made to work by all the
fancies that you guys have put into the implementation.

In proper code, objects would be created on the heap (with new).
You better do that anyway as you don't know how big your stack is and how big
the objects are that some 3rd-party library creates. (Esp. if you have multiple
threads, you cannot assume stacks to grow infinitely.)

Yes, with C++ you have to do life cycle management of object references.

I know, by keeping SAGA out of the memory management business, the price for
this clarity is manual destroying of objects.
But: we should stop arguing over artificial examples that are only designed
for proving a certain argument.
Sessions are by definition rather static; in a real application I can not see
a session to be destroyed before the end of the program anyway.


> All that is simple to do in the SAGA implementation, which
> _knows_ where it is inherited, and which will do ref
> counting anyway...

No way. SAGA needs to stay away from object lifecycle management.

> Again, I think your proposal is simple and it works, so its
> an valid option -- but IMHO it makes programming SAGA
> applications an ugly business.

Yes, in less advanced languages there is some price to pay.
But there is no single reason to spoil the language-independent spec, just
because C++ doesn't have proper memory management.


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/