[PATCH 1/1] Add module_semaphore_free() to destroy semaphore...

[sub]

[...]
> > To tell the truth , the use of platform-specific functions instead of the 
> > wrappers (such as module_semaphore_...) is strange to me.

> I wouldn't call an api provided by pthread's platform specific, and
> there's no need for a wrapper so it shouldn't exist.

Thanks for remarks.
At the moment, semaphores are implemented by pthread. After some time a need to 
change the implementation. Will again need to modify all files of modules 
instead
of changing several functions.

>> I proceeded  from the assumption that the design of a module API develops 
>> towards wrapping the platform specific calls, to say nothing of the hiding 
>> the semaphore's implementation.

> I'm not sure what your getting at here.  The purpose of module_foo() is
> to provide functions that are useful in multiple modules, but if there's
> no need for a utility function then there's no need for a module_foo()

This is true, but I'm not talking about it.
In case with semaphore's functions, the semantics of 'module_fo ()' is to 
create a resource  or release the resource careful. 
This semantics may require more actions than a single call sem_init or 
sem_destroy.
Although at this stage module_semaphore_init really degenerates into the single 
sem_init. 
But I'm not sure that to formalize this degeneracy
by placing directly call sem_init in the module files.
IMO, the API of SD output modules  is higher level of abstraction (relative to 
the used libraries,  including pthread ). 
Therefore, the semantics of pthread API does
not match the semantics of the API of SD output modules.
Proposing to use sem_init instead of module_semaphore_init, You substitute the 
semantics of the pthread API for the semantics of the output modules API. 
This coupling makes the code of modules inflexible.

    Anatol