Hi Pascal,
Quoting [Pascal Kleijer] (Nov 11 2005):
>
> Hello,
>
> If you are working on a C++ model why work with flags? Simply use the
> power of the language and use inheritance. A core abstract class give
> the general common stuff and then you can derivate as wished to a
> synchronous and asynchronous class.
>
> In that case the calls can remain the same but the behavior changes:
>
> saga::directory d= new SynchronousDirectory()
> or
> saga::directory d= new AsynchronousDirectory()
>
>
> std::list<string> l;
> saga::task t = d.list(&l);
> t.wait();
> do something with l
>
> In the synchronous case the list is filled up and in the asynchronous
> case the list will be filled only after the task has properly ended.
> Calling the wait on the sync task will directly return.
What about our example of doing a sync seek, then a async
write on a file?
saga::file f1 = new saga::SyncFile (url);
saga::file f2 = new saga::AsyncFile (url);
f1.seek (100, SEEK_CUR);
saga::task t = f2.read (100, buffer);
f2 still stands on the 0 position. So you can't mix sync
and async calls on a object in that way. Also, your sync
calls do return a task (probably finished), not an error
code. Well, that problem pops up in most proposals we have
so far...
> So:
> 1) You have uniformed calls.
> 2) You can overwrite the class without affecting the definition.
> 3) You can interchange the classes without touching your code.
Right, good points...
> Having the sync flag set on the fly and change the behavior might be
> very difficult to handle in case of race conditions. I'm used to code
> multi-tasked applications that often share numerous objects and changing
> the sync/async behavior will be a real problem if you don't take
> care. Debug that sort of code is hell.
Yes, agree. Nobody really seems to like flags in terms of
implementation. But well, it looks simple on API level,
that the appealing part...
Thanks, Andre.
> my 2ct.
>
> 'Andre Merzky' wrote:
> >Hmm, I thought so as well, you know. But actually, error
> >conditions are flagged by excptions, so we would not return
> >errors anyway. So it does not matter if e.g. mkdir_sync ()
> >returns a task: it would not be used anyway. (If the task
> >gets returned it is Finished. If it failes, an error is
> >thrown.)
> >
> >OTOH, for calls which do return infos this is different:
> >directory.ls (); would normally return a list of strings I
> >guess. With the proposed model, the list would need to be
> >returned in I/O parameters, such as:
> >
> > std::list<string> l;
> > d.ls_sync (&l);
> >
> >So, the problems are not error conditions, but return values
> >I guess.
> >
> >However, similar considerations hold for the other task
> >models: at least the signature of the method calls might
> >look different for synchroneous and asynchroneous calls:
> >
> > sync in version B:
> >
> > std::list<string> l = d.sync.ls ();
> >
> > async in version B:
> >
> > std::list<string> l;
> > saga::task t = d.sync.ls (&l);
> >
> >I created some more verbose examples at
> >
> > http://wiki.cct.lsu.edu/saga/space/Task+Models
> >
> >(see bottom of page) -- I hope that helps the discussion.
> >Feel free to change/edit/correct them, and in fact to edit
> >that page.
> >
> >Again: the cuurent discussion does ONLY affect the C++
> >language binding for now!
> >
> >Cheers, Andre.
> >
> >
> >
> >Quoting [Hartmut Kaiser] (Nov 08 2005):
> >>The main question is, do we need to have different return values from
> >>sync/async operations or not. It's kind of unusual to get a task from a
> >>'normal' sync operation, even more because this task is usable for return
> >>value retrieval only.
> >>
> >>Regards Hartmut
--
+-----------------------------------------------------------------+
| Andre Merzky | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science | mail: merzky(a)cs.vu.nl |
| De Boelelaan 1083a | www: http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands | |
+-----------------------------------------------------------------+
