August 2005 - saga-rg - lists.ogf.org

object hierarchy for task factories...
by Andre Merzky 30 Aug '05

30 Aug '05

Hi all, during implementing SAGA in C++, we came upon a naming issue. Currently, the task factories are individual object types in the saga name space, so we have a saga::file_task_factory, saga::logical_file_task_factory etc. A better way to structure that might be (proposal), to have the task factories in the respective name spaces, i.e. saga::file::task_factory and sga::logical_file::task_factory etc. That would not change the look and feel of the API really, its basically about naming. However, the implementation is cleaner. One advantage is the following: If an enum gets defined in a class (as the flags for file opening), they have to be either redefined in the task factory with the same values (ugh), or need to be fully qualified in the task_factory (e.g.: my_task_factory.open (url, task::Create). Also Ugh. Having the task factory in the name space of the respective objects would resolve that. I am not sure about SIDL, but it might actually be an unclean point in the specification right now as well. As a side note, related to yesterdays question about what object should have the task model implemented: it might be best to include a marker interface, and to tag those objects in the spec. Thats the most explicit way I can think of right now. Comments, as usually, welcome... Very much so actually... 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

enums name space...
by Andre Merzky 29 Aug '05

29 Aug '05

Hi, for some packages in the strawman, enums are defined directly in the saga name space. I propose to move them into the class definitions, to avoid confusion from too many enums in the same name space. As an example, we have: state (task), stream_state, job_state. I thinbk it would be better to have task::state, stream::state, job::state. Any comments? Cheers, 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

task on all classes?
by Andre Merzky 29 Aug '05

29 Aug '05

Hi all, There are several SAGA classes and interfaces where the spec is not perfectly clear if the task model should be applied or not. For the stream packages, I think it makes no sense to have tasks/task_factories for the StreamServer and the Multiplexer classes, as both are already working asynchroneous. In fact, I think it would be good to synchronize their interfaces with that of the task interface, e.g. use wait, getState etc. For some of the generic interface, such as context, attributes, permissions, session, namespaces, we are silent about any task incarnation. As session and context are intended to represent local information, and don't have any potentially long running methods attached, I think that tasks would be superflous and confusing on them. For permissions, attributes and namespaces the situation is different, as the setting/query methods for them can very well invoke a slow remote interaction, and hence would benefit from the asynchroneous task model, so I think we should include it here. Comments would be welcome. On silence, I am going to include some specifica alongb these lines in the strawman. Best regards, 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

task model for interfaces?
by Andre Merzky 27 Aug '05

27 Aug '05

Hi all, the strawman defines that the task moel needs to be implemented for all SAGA objects. Just to clearify: I assume it needs also to be implemented for all interfaces, e.g. namespace and attributes? As these interfaces may also trigger remote operations, the async task model makes sense here as well, not only on the objects. Cheers, 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

sessions at GGF15
by Andre Merzky 26 Aug '05

26 Aug '05

Hi group, we plan to have the following sessions at GGF-15 - please let us know if you have comments: Session 1: SAGA Use Case Mappings The session will present the SAGA API Draft, and publicly discuss the mapping of the API to the SAGA Use Cases. - Administrativa, GGF agenda bashing (10 min) - presentation of SAGA API (20 min) - mapping 3 Use Cases to API (60 min) Session 2: SAGA API Discussion The session will host a low level discussion of the current SAGA API draft. The draft is supposed to advance to submission status soon. The session will also host a discussion of higher level issues, such as the handling of future API extensions, and language bindings. - agenda bashing ( 5 min) - API discussion (60 min) - General discussion (25 min) Session 3: SAGA Requirement Doc Discussion The group will work on the current draft of the Requirement Document. - agenda bashing ( 5 min) - document discussion (85 min) Cheers, 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 | | +-----------------------------------------------------------------+

3 7

Jobs and SandBoxing
by Andre Merzky 25 Aug '05

25 Aug '05

Hallihallo! [For the attentive reader: right, the subject of the 'other' mail should have been "Jobs and GetState", not "Tasks and GetState" - sorry] Another comment I got about jobs in SAGA is: how is sandboxing supported? Can I at least determine if my job runs in a sandbox? Or at least what it's 'cwd' is? Does a job have a unique job ID I can use to identify it? (That question is related to the session persistency discussed in another thread I think). Any opinions? Cheers, 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 | | +-----------------------------------------------------------------+

3 10

BOUNCE saga-rg@ggf.org: Admin request of type /\bcancel\b/i at line 4 Admin request of type /\bcancel\b/i at line 6 (fwd)
by Shantenu Jha 25 Aug '05

25 Aug '05

From: Andre Merzky <andre(a)merzky.net> To: Tom Goodale <goodale(a)cct.lsu.edu> Cc: Simple API for Grid Applications WG <saga-rg(a)ggf.org> Subject: Re: [saga-rg] wait on tasks... I think it would be nice to avoid the need for try/catch for wait, at least for the situation when the task finishes peacefully (enters Finished state). I agree that a concurrent cancel from the same application should be catchable, as that indicates a flaw in application logic (cancel in one thread, wait in another). So your proposed policy of allowing a wait to simply return success as long as the parameters are in a usable state, or to simply fails as long as the task might get into Finished state, would be a good solution. Andre. Quoting [Tom Goodale] (Aug 25 2005): > > On Thu, 25 Aug 2005, Andre Merzky wrote: > >> Quoting [Tom Goodale] (Aug 25 2005): >>> >>> On Wed, 17 Aug 2005, Andre Merzky wrote: >>> >>>> Hi all, >>>> >>>> the wait currently throws a NotRunning exception if the tast >>>> is not running anymore. That basically mean that _every_ >>>> wait has to be put into a try/catch, since the programmer >>>> does not know in advance if the task is still active. >>> >>> The can do a getState on the task. >> >> You have a race condition then: >> >> state = task.getState (); >> >> # task finishes now >> >> if ( state == Running ) >> { >> task.wait (-1.0); # throws an NotRunning exception >> } >> >> So that does not help. > > Good point, but it does if we also change the exception, although they > still might want to put a try around it to catch someone cancelling the > task in the meantime; on the other hand since that could only happen from > within the same program, it's probably something the programmer can decide > if they need to do. > > Tom -- +-----------------------------------------------------------------+ | 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

wait on tasks...
by Andre Merzky 25 Aug '05

25 Aug '05

Hi all, the wait currently throws a NotRunning exception if the tast is not running anymore. That basically mean that _every_ wait has to be put into a try/catch, since the programmer does not know in advance if the task is still active. We would like to propose to change that behaviour, and just return immediately on wait, even if it is called multiple times. A NotRunning exception should only be thrown if the task was cancelled before. The same should hold for the TaskContainer. Any opinions to that? Cheers, 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 | | +-----------------------------------------------------------------+

2 3

issue list for todays call...
by Andre Merzky 25 Aug '05

25 Aug '05

Hi all, here is the issue list as of today. We stopped discussion on issue No. 23 last time, and will continue from there I guess. Cheers, 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

Details for call 25/8/05 (reminder)
by Tom Goodale 24 Aug '05

24 Aug '05

Hi, this is just to remind you of the details of tomorrow's call. If you have any agenda items, please send them. Cheers, Tom ---------- Forwarded message ---------- Date: Thu, 18 Aug 2005 16:41:53 +0100 (BST) From: Tom Goodale <goodale(a)cct.lsu.edu> To: Simple API for Grid Applications WG <saga-rg(a)ggf.org> Subject: [saga-rg] Details for call 25/8/05 Hi, Sorry once again for today's problems, I have now setup a call for next week Date: Thu 25 August 2005 Time: 1700 Central European Summer Time 1600 British Summer Time 1000 Central Summer Time 0800 Pacific Summer Time Number: 0844 888 8888 (UK) 01805 004 102 (Germany) +44 870 088 5706 (Others) Code: 808044 If anyone has specific agenda items, please send them to the list so I can compile an agenda for next week. I will try to send a reminder out on Tuesday and an agenda late on Wednesday. Cheers, Tom

1 0