Hi Gregor, for most discussions in SAGA, tasks have been considered as equivalent to threads (so exist purely for the sake of async operations). As such, we did not see the need for finer control (e.g. suspend or signaling). However, you are right, that might be too simplistic in the long run. Having suspend for tasks like file transfer, and also a resume, begs for the question of state of tasks. Also, as you mention, it requires support in the backend, and hence introspection. The use cases we have for asynchroneous operations right now are, AFAIK, - async RPC calls (not in the API right now) - async file and stream read/writes The use cases for both ops are not intended to run on a backend that supports suspend/resume. Although the saga task model now provides async. for almost _all_ operations, its not immediately clear to me what a suspend state would imply in terms of semantics to these calls. I think that the large file transfer example you cite is the most common use case with support for susp/resume (RFT). We do not have it explicitely in our use cases right now. The only obvious case in saga are jobs, where we have the separate suspend/resume methods. So, you are right, if we think of conversion between jobs and tasks, we should also consider suspends. It might be best to shelve that point and come back to it in the next API version. Well, that is a perfect task for the upcoming RG! :-P Well, having said that, I think its still useful to have the task API for jobs (not vice versa). As the task states and methods are a real subset of the job states and methods, that should be trivial (kind of) :-) Cheers, Andre. Quoting [Gregor von Laszewski] (Feb 05 2006):
I had not had the time to review all of this, but I like to suggest that a "task" has also the option to be suspended or resumed. you also need an introspector to actually find out if for example a particular feature has been implemented or not. You ma be in the need to define NonSuspendableTasks in which you for example do not have resume or suspend options. This has actually implications on how we intend to use this as part of future portal developments. Hers the "tasks" could encapsulate a lotincluding file transfers and job submissions ... As a file transfer as wll as a job could be suspended its important that both have at least the ability to be supported in that way.
Gregor
Andre Merzky wrote:
Nice, thanks!
To save everybody from the need to search GrodForge, here is the table from the document:
bes::job saga::task saga::job
New Pending Queued Pending Running Queued StagingIn Running PreExecution ExecutionPending Running PreExecution Running Running Running ExecutionComplete Running PostExecution StagingOut Running PostExecution CleaningUp Running PostExecution ShuttingDown Running PostExecution Suspended Running Suspend Suspended Running SuspendUser Suspended Running SuspendSystem NotKnown Unknown Unknown Other Unknown Unknown Done Done DoneOK Terminated Failed DoneFail Exception Failed DoneFail HoldSystem HoldUser Hold
In repspect to the original topic (task/job), these map fairly well to the task and job states we have, but are more detailed. I could not find an equivalent for Hold.
Are there other models defined in GGF, or is that _THE_ model?
Cheers, Andre.
Quoting [Steven Newhouse] (Feb 05 2006):
Date: Sun, 05 Feb 2006 07:04:28 +0000 From: Steven Newhouse
To: Andre Merzky CC: Simple API for Grid Applications WG Subject: Re: [saga-rg] job states... Hi Andre,
The Basic Execution Service WG has done some work on defining an activity state. You may want to have a look at that - there should be a copy on gridforge - somewhere!
Steven
-- "So much time, so little to do..." -- Garfield