Hiho, I can't remember exactly where the sugegstion came from, but here it is anyway. Wouldn't it be useful to have jobs implementing the task interface? Well, the advatages would be: - you can put jobs into tak containers, and wait() for them to change state/finish - if we have notification on tasks (see earlier mail from November or so), we have now notification on jobs as well, w/o the need to introduce a new mechanism - it seems simple to map the job states to task states: Done -> DoneOK Failed -> DoneFail all others -> Running (as a side note, we should consider have the same names for Done and Failed...) The only difference I see in terms of semantic is that tasks can be Pending - i.e. not yet started. Jobs can't, as soon as you create them, they are at least Queued. However, that is a topic I wated to open anyway: One of our earliest use cases is bulk job submission (from Hrabri/DRMAA). The current API does not allow to implement that use case efficiently - the only possibility is: for ( int i = 0; i < 1.000.000; i++ ) { my_jobs[i] = job_server.submit_job (job_description[i]); } Having jobs more task like would help: for ( int i = 0; i < 1.000.000; i++ ) { task_container.add_task (job_server.create_job (job_description[i])); } task_container.run (); The semantics would be now: job = job_server.create_job (job_description); // job is pending now job.run (); // job is queued now, or whatever - see previous mail. That argumentation is very similar to the one we hade about task creation: there we have: task t1 = file.read <async> (...); // t1 is running task t2 = file.read <task> (...); // t2 is pending t2.run (); // t2 is running same for jobs then: job j1 = job_server.submit_job <async> (...); // t1 is running job j2 = job_server.create_job <task> (...); // t2 is pending j2.run (); // j2 is running Feedback as always would be very welcome. An issue in that respect is in the issue list (since a couple of weeks actually). Best regards, Andre. -- "So much time, so little to do..." -- Garfield
