[saga-rg] tasks and jobs...

[Thilo Kielmann]

Ouch! Andre has a pretty good punch! 

I agree with his proposal ;-)

Thilo

On Mon, Feb 06, 2006 at 04:22:55PM +0100, Andre Merzky wrote:
> X-Original-To: kielmann at localhost
> Delivered-To: kielmann at localhost.cs.vu.nl
> Date: Mon, 6 Feb 2006 16:22:55 +0100
> From: Andre Merzky <andre at merzky.net>
> To: Thilo Kielmann <kielmann at cs.vu.nl>
> Cc: saga-rg at ggf.org
> Subject: Re: [saga-rg] tasks and jobs...
> 
> Hi, 
> 
> I just had a discussion with Thilo about the topic, as he
> and me obviously talked somewhat orthogonal to each other...
> 
> Well, now we have the same opinion, kind of, and I have
> barely any bruises...  Anyway, I want to summarize our point
> here, as I probably was not really clear in my initial post.
> 
> Sorry if re-iteration of the topic bores you...
> 
> So, we have tasks, which represent async operations, with a
> couple of states attached, and the ability to call run(),
> wait() and cancel() on these.  And we can collect them in
> containers, and wait() on many of these tasks conveniently.
> 
> And then we have jobs, which represent remote executables,
> with a couple of states attached, and the ability to call
> run (== create them), wait() and cancel().  And some more
> methods.  And we can't collect them in containers right now,
> but would like to.
> 
> You see the similarities, right?  Its even more obvious in
> code:
> 
>   Tasks:
>   --------------------------------------------
>     task_container tc;
>     task t = file.copy <saga::task> (...);
>          t.run  (   );
>          t.wait (1.0);
>   
>         tc.add  (t);
>         tc.wait ( );
>   --------------------------------------------
>   
>   Jobs:
>   --------------------------------------------
>     job_container jc;
>     job j = job_server.submit (job_descr);
>         j.wait (1.0);
>   
>        jc.add  (j);
>        jc.wait ( );
>   --------------------------------------------
>   
>   slightly changed:
>   --------------------------------------------
>     job_container jc;
>   ! job j = job_server.create (job_descr);
>   +     j.run  (   );
>         j.wait (1.0);
>   
>        jc.add  (j);
>        jc.wait ( );
>   --------------------------------------------
> 
> The similarities are obvious I think.  Now, if job would
> IMPLEMENT the task interface (or inherit from task), we
> would unify both classes, and hence:
> 
>   - simplify jobs (leave only those methods which are
>     specific to jobs, like migrate, signal, ...
>   
>   - allow to out jobs into task containers, efficiently
>     handling large amounts of jobs and other tasks
> 
>   - have the API and used paradigms more uniform.
> 
> Also, if later tasks get suspendable, as Gregor rightly
> suggested, we can move more methods to tasks, w/o breaking
> the paradigms.
> 
> In terms of state, following mappings would be appropriate:
> 
>   job::Pending -> task::Pending
>   job::Done    -> task::Done
>   job::Failed  -> task::Failed
>   job::???     -> task::Cancelled
> 
>   job::Queued,Running,Pre/Poststaging,... -> task::Running
> 
> So, no adjustements to the statet models are needed AFAICS,
> apart from Cancelled 
> (Does it make sense   on jobs?  
>  Should job::stop     be job::cancel?  
>  Should tasks::cancel be task::job?)
> 
> Hope that clearifies things.  I think Gregor was on target
> with his remarks, and Hartmut signalled consent as well.
> And I think I convinced Thilo (Andre rubs his bruises).
> 
> Unless there is any opposition, I'll go ahead and document
> that in the strawman then, ok?
> 
> Cheers, Andre.
> 
> 
> Quoting [Thilo Kielmann] (Feb 04 2006):
> > Date: Sat, 4 Feb 2006 22:29:41 +0100
> > From: Thilo Kielmann <kielmann at cs.vu.nl>
> > To: saga-rg at ggf.org
> > Subject: Re: [saga-rg] tasks and jobs...
> > 
> > > Wouldn't it be useful to have jobs implementing the task
> > > interface?
> > 
> > Certainly, no.
> > Jobs and Tasks are two different things, and they are this on purpose.
> > 
> > However, Tasks always have been the mechanism for asynchronous operation,
> > which is kind-of obsoleted by having asynchronous ops directly.
> > 
> > If you want to work on the "S" of SAGA: why not unify both Tasks and Jobs
> > into a better "Job" notion, and do local asynchronous operations via
> > async, local calls?
> > 
> > Thilo
> -- 
> "So much time, so little to do..."  -- Garfield



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