Hi Jose, On Tue, 5 Sep 2006, Jose R. Valverde wrote:
I'm working on a DRMAA-C binding for EGEE (currently LCG2, and afterwards gLite).
Glad to hear this.
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).
Your comments are absolutely welcome. I encountered we dealt already with some of them, but we failed to update the C binding spec or at least file related items to Grid Forge.
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).
No. It is possible to make a -lpthread shared dependency integral part of the DRMAA library. Details how to achieve this can be found under http://www.ggf.org/mail_archive/drmaa-wg/2006/05/msg00012.html also when you follow the discussion under http://gridengine.sunsource.net/servlets/BrowseList?list=users&by=thread&from=12304 you see that hiding the -lphtread dependency works on all OS platforms except on FreeBSD due to a bug.
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.
This section depends on the issue above.
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
True. Also note there is a second errno value missing in the published C DRMAA spec. There is a mail I sent in July 2006 to this mailing list with the corrected list of errno values. I made this mail available as attachement of a corresponding DRMAA C binding issue https://forge.gridforum.org/sf/go/artf5569?nav=1 since DRMAA WG mail archieve is still broken.
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.
True. I added https://forge.gridforum.org/sf/go/artf5570?nav=1 for this.
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
Thanks. I filed it as https://forge.gridforum.org/sf/go/artf5571?nav=1 Regards, Andreas