November 2005 - gridrpc-wg

SAGA F2F at SC05 - ROOM CHANGE!
by Andre Merzky 17 Nov '05

17 Nov '05

Hi all, good news: thanks to Julie Wulf we got a room on-site at SC-05, which will simplify attendance for a number of people :-). So, we meet in +----------+ | Room 205 | +----------+ at the Convention Center, on Thursday from 13:00 to 18:00. A number of people have conflicts: don't hesitate to drop in part-time... Please note that there will be no power in the room... :-( Cheers, Andre. ----- Forwarded message from Julie Wulf-Knoerzer <wulf(a)ggf.org> ----- > Date: Wed, 16 Nov 2005 11:21:22 -0600 > To: Andre Merzky <andre(a)merzky.net> > From: Julie Wulf-Knoerzer <wulf(a)ggf.org> > Subject: Re: Room for Thursday > > I've reserved room 205 (across from where the GFSG f2f was). > Note there is no power strips in the room. If anyone asks, > you are with me (-: > > Julie ----- End forwarded message ----- -- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+

1 0

Fwd (andre@merzky.net): Re: [saga-rg] Meeting at SC05 - Reminder
by Andre Merzky 11 Nov '05

11 Nov '05

Hi, FYI, the final meeting details for the SAGA F2F meeting at SC05: Location: Room 526 (Emerald Suite) 6th Avenue Inn 2000 6th Avenue, Seattle, WA 98121 (green location on the map) Time: 13:00 to 18:00 Agenda: - WG charter (finalize) - SAGA task model (finalize) - use case evaluation (update, feed into req. doc) The attached map shows the convention center in orange, and the meeting location in green. Cheers, cu next week :-) Andre. On Nov 8, 2005, at 10:48 PM, Andre Merzky wrote: > > Hi all, > > this is just a reminder (and confirmation) that we will have > a SAGA F2F meeting in Seattle on Thursday, November 17th 2005. > We will meet in Ed's hotel suite (it will have a small > meeting room), I'll send the exact location (room number) as > soon as I know it. > > Cheers, cu next week, > > Andre. -- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+

1 0

Re: [saga-rg] Task model...
by 'Andre Merzky' 09 Nov '05

09 Nov '05

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

1 0

Re: [saga-rg] Task model...
by Andre Merzky 09 Nov '05

09 Nov '05

Ah, right, sorry, I forgot about that model... There are two points to it, really: a) synchroneous calls alse return a (finished) task b) a object can be either synchroneous or asynchroneous (a) is actually a more general point: it would be interesting for the other models we listed earlier as well. I kind of like it, as it makes implementation simplier, but OTOH it makes error handlin somewhat more complex for the synchroneous case, as you need to query the task state and error condition explicitely. (b) was indeed discussed, but if my memory does not trick me, it was discarded as it does not allow to - create a directory object - do a synchroneous mkdir - copy 100 files asynchroneously into that dir you cannot mix sync and async calls in that model. Is that something you would think is no problem? We don't have very detailed use cases on asynchroneous calls, apart from what we learned from the GridRPC folx. It might be worth to write some down explicitely... Cheers, Andre. Quoting [Pascal Kleijer] (Nov 07 2005): > > Hello, > > Here is an example of what was discussed in Boston. > > // Type g1: No factory > // The class has a flag in the constructor to tell if it work > // synchronous or not. > Directory d= new Directory("\", true); > Task t= d.mkdir("test\"); > t.wait(); > > //Type g2: with factory > DirectoryFactory f= new SynchronousDirectoryFactory(); > Directory d= f.newInstance("\"); > Task t= d.mkdir("test"); > t.wait(); > > Whatever the nature of the call, synchronous or not, a task is returned. > A synchronous call will return a finished task. By providing a tight > encapsulation it is possible to sub-class easily to add new features. > For example you can implement a DebugDirectory class easily adding some > extra debugging information without having to change the main code. > > My preference goes to the g1 case since it is the most direct and no > factory is needed. Pattern design (g2) is nice, but I'm not sure if this > is really necessary for this model. > > I know this solution is really OO designed, but that?s just because I > always think in terms of objects. > > > Best regards, > Pascal Kleijer > > > >Hi Pascal, > > > >there have been more models in discussion in Boston, true > >enough. However, I can't really figure out what model you > >refer to. Some example code would be helpful :-) > > > >Cheers, Andre. > > > > > >Quoting [pascal.kleijer(a)knd.biglobe.ne.jp] (Nov 03 2005): > >>Hello all, > >> > >>Lets enter the arena if it is not too late, sorry for that. > >>I do agree with many things that have been discussed here. > >>Being myself a POP (pattern oriented programming) and OOP > >>(Object Oriented programming) guy I tend to favor nicely > >>encapsulated models. > >> > >>As mentioned by Tom, the template is possible in Java as > >>well. But that forces the usage of Java 5.0 (aka 1.5) at > >>least. This isn't recommended since many programs > >>still run with 1.4. Using them would probably create a very > >>different binding in Java, C++ or Python, which would end up > >>in 2 different SAGA implementations/usage, one for OO > >>languages and one for old fashioned procedurals. > >> > >>As to exposing the different implementation to the user I > >>think this could be avoided in OO languages, or at least it > >>should not be as obvious as in 4a2. During the GGF meeting > >>their was a last minute discussion about a `g' solution > >>which is pretty much pure OO design with a simple method > >>call whatever model is used. This is I think a good choice > >>for an OO point of view. You can derivate an abstract class > >>to specialized classes with synchronous or asynchronous > >>implementation. This would even open the room for sub > >>classing it to add custom code for debugging for example or > >>other treatment without affecting the initial code. > >>Depending on how the programming is tackled factories aren't > >>necessary. The problem might come when implementation is > >>made in procedural languages, it might be necessary to add > >>additional parameters to the constructor or the calls. > >> > >>I don't have the time this morning to make a sample > >>code. But I hope you got the idea. > >> > >>Best Regards, > >>Pascal Kleijer > >> > >>>My vote is for 4a1. (Which was option D in our original discussion I > >>>believe.) > >>> > >>>Cheers, > >>> > >>>Tom > >>> > >>>On Thu, 3 Nov 2005, Andre Merzky wrote: > >>> > >>>>Hi John, Thilo, Group, > >>>> > >>>>Hartmut and I would like to argue about the C++ bindings. > >>>>We would like to come to an agreement soon, as our > >>>>implementation is dealing with the async part right now. > >>>> > >>>>As reminder: > >>>> > >>>>--------------------------------------------------------------------- > >>>>Example 4a: more versions in C++ > >>>> > >>>>4a1: d.mkdir ("test/"); > >>>> d.mkdir_sync ("test/"); // same > >>>> saga::task t_1 = d.mkdir_async ("test/"); > >>>> saga::task t_2 = d.mkdir_task ("test/"); > >>>> > >>>>4a2: d.mkdir ("test/"); > >>>> d.sync .mkdir ("test/"); // same > >>>> saga::task t_1 = d.async.mkdir ("test/"); > >>>> saga::task t_2 = d.task .mkdir ("test/"); > >>>> > >>>>4a3: d.mkdir ("test/"); > >>>> d.mkdir <sync> ("test/"); // same > >>>> saga::task t_1 = d.mkdir <async> ("test/"); > >>>> saga::task t_2 = d.mkdir <task> ("test/"); > >>>> --------------------------------------------------------------------- > >>>> > >>>> > >>>>Quoting [John Shalf] (Nov 02 2005): > >>>>>> Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!) > >>>>>I prefer 4a1 because it is more readable and the implementation would > >>>>>be quite straightforward. > >>>>You favour 4a1. We think that implementation is very straight > >>>>forward for all three versions. Readability seems not much > >>>>different to me, and might largely be a matter of taste. > >>>> > >>>> > >>>>>It is also a familiar paradigm for any MPI > >>>>>programmers and anyone who has played with various proprietary Async > >>>>>I/O implementations. (its a very familiar and conventional approach) > >>>>Well, these are C-API's. Is there a C++ binding for MPI, > >>>>and does it look the same? > >>>> > >>>> > >>>>>I kind of like 4a2 as well from the standpoint of a C++ programmer > >>>>>(even with Andre's syntax corrections). However, the resulting > >>>>>bindings will not be very consistent with the approach we would take > >>>>>for Fortran or C bindings (eg. those would likely look more like > >>>>>4a1). > >>>>But, well, that is the idea of the language binding! I agree > >>>>that C and Fortran would look more like 4a1, of course. But that > >>>>is no reason that C++ should look like that as well, or Java, > >>>>Perl etc. > >>>> > >>>> > >>>>>It is not really much more readable than 4a1. Therefore, I'm > >>>>>uncertain if it is worth fragmenting our approach to bindings in > >>>>>different languages when there is not a clear benefit in terms of > >>>>>readability or implementation complexity. > >>>>I think that 4a2/4a3 actually allow nicer implementations, as it > >>>>allows to have the different async parts somewhat separate from > >>>>the sync parts. We think its nicer :-) > >>>> > >>>> > >>>>>I do a lot of C++ programming, but I find the 4a3 option a bit > >>>>>obscure both in terms of readability and any advantages it might > >>>>>confer in terms of implementation. > >>>>Hehe - I thought the same :-) Hartmut likes that version very > >>>>much. To me it appealed after pondering over it for a couple of > >>>>days. Now I think it is cute, and quite expressive. > >>>> > >>>> > >>>>>It would certainly be easier to > >>>>>create multi-language bindings for a single code base if we stick > >>>>>with something more conventional like 4a1. > >>>>I think that C and Fortran bindings for this part are straight > >>>>forward anyway, there is no need to reflect that in C++... > >>>> > >>>> > >>>>>Each approach is equally readable to me (less so for 4a3). I'm > >>>>>certainly open to any additional information on how the 4a2 and 4a3 > >>>>>approaches could simplify implementation. > >>>>The main point really is that the object itself has only the sync > >>>>method calls, and the async calls can be put into separate > >>>>header/sources easily, and build (by default) on top of the sync > >>>>calls. Of course, you can do that with all three versions, but > >>>>its not as obvious in 4a1. > >>>> > >>>> > >>>>>If the other approaches > >>>>>can offer some implementation benefits, then maybe I'd give them > >>>>>extra consideration, but otherwise, I would prefer a more > >>>>>conventional approach like 4a1. > >>>>I would vote for 4a2 or 4a3 (in that order), but 4a1 would be ok > >>>>if the majority likes that most, of course. Basically its > >>>>a matter of taste I think. I am happy that the general point > >>>>seems accaptable to all so far: having sync, async, and task > >>>>versions of the calls, w/o explicit task factory. > >>>> > >>>>>The only implementation I'm outright > >>>>>against is the 4b example. > >>>>Good! :-) > >>>> > >>>>Thanks, Andre. > >>>> > >>>> > >>>>>-john > >>>> > >>>> > >>>> > >>> > > > > > > > -- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+

2 2