Am 22.06.2011 um 13:18 schrieb Mariusz MamoĊski:
On 22 June 2011 12:37, Daniel Gruber <dgruber@univa.com> wrote:
Hi all,
I've following findings:
* MUTLITHREADING safety should be a capabilty since it is implementation specific. Also source code portability requires it.
* latex format error in line 364
* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations accessible for the user running the DRMAA-based application."
Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible" is a better wording.
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments). Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate this is made *very* explicit, that one might need request a job category this is not mentioned in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request approach. The JobCategory in the spec could be renamed to Category if needed.
this is fine with me, but lets call it ReservationCategory or Category, not JobCategory.
I also thought on ReservationCategory but this needs to add it as a different new concept in the spec and also requires new functions (for retrieving all ReservationCategories). Since both (ReservationCategory and JobCategory) are just strings and in Univa Grid Engine for example both categories maps to the same concept (additional resource requests, which are appended). I would rather change "JobCategory" to "Category" as a generic category name for job or reservation requests.
Anyhow it would be good to add multiple category strings - but this is going to be an implementation specific enhancement if needed.
i'm not sure if i understood you correctly but i don't think that any implementation can change this attribute from scalar to vector, as this would brake binary compatibility. We should decide globally if we want the jobCategory to be string or vector of strings.
No, not changing the method itself. I thought about introducing a completely new implementation specific function, which is not aligned to the standard. I think we already discussed adding a vector type but I AFAIR it was rejected because we then have to handle mutually problems like exclusive resource requests. But for simplicity one way would be the make this again transparent for the standard (i.e. how merging of resource requests is done, it up to the DRMAA implementation). Cheers, Daniel
Cheers,
Daniel -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Cheers, -- Mariusz