[DRMAA-WG] DRMAA-C binding comments

[Jose R. Valverde]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/drmaa-wg/attachments/20060905/0a9a1655/attachment.pgp