I'm working on a DRMAA-C binding for EGEE (currently LCG2, and afterwards gLite). In the process I've noted some noteworthy features in the C binding specification. I guess this has been already noted before, so please do forgive me if it is a repetition. I've tried to check the list archives, but it's proving a more cumbresome task than I find desirable (or manageable within my timeframe). So, these are some comments to the published standard for the C binding (I may send other messages as I procceed with the binding): Section 4 =========
into an application at run time. An application SHALL NOT be required to directly load more than one library in order to use a DRMAA implementation. The name by which the run time linker will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This requirement actually precludes making the library multithread- safe, since that requires awareness of threads and therefore requires linking with the pthreads library (-lpthread). It is arguable if this should be done by the user and not DRMAA, but then Section 2.2 of the DRMAA specification (GFD.022) states
2.2 Thread Safety The authors expect that developers will link to a DRMAA library from serial and multithreaded codes; hence it is RECOMMENDED a DRMAA library be thread-safe, and allow a multithreaded application to use DRMAA interfaces without any explicit synchronization among the application threads. It is RECOMMENDED that the DRMAA implementers label their implementations as thread safe if they meet the above criteria. Providers of non thread safe DRMAA
This leads to an inconsistency and an imposibility to code the C-binding API as described. I suggest changing the C-binding API documentation to either relax the linking requirements or state that the threads library is an exception. The reason is, if I have a thread-safe library and use it from a non-threaded program it won't be evident that I still need to include -lpthreads anyway. And vice-versa, if I have a non-thread safe library and use it on a multi-threaded environment, as -lpthread will be linked, I won't realize it is not been used by the library and hence it is not thread-safe. Section 5.1.5 ============= DRMAA_ERRNO_NO_MORE_ELEMENTS is not included, but it is a required return value for the string vector manipulation functions Section 5.2 Section 5.2.[789] ================= drmaa_release_*() functions are declared to return void in the function prototypes of 5.2, but later defined to return various DRMAA_ERRNO values (which would make them 'int'). I guess that if one does indeed code them as returning int and then ignores their return value as if they were void, it is harmless, but still it is an inconsistency to address. Section 5.3.1.2 =============== A typo on the last return value: should be DRMAA_ERRNO_ALREADY_ACTIVE_SESSION instead of DRMAA_ERRNO_ERRNO_ALREADY_ACTIVE_SESSION j -- Jose R. Valverde EMBnet/CNB