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

[Trevor Saunders]

On Fri, Dec 09, 2011 at 09:19:19AM +0400, sub wrote:
> [...]
> > > 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

I think "implemented by" is interesting way to say we use.

in any case your going to need to do some justifying of the claim we
might need to change in any reasonable time period, because saying it
doesn't make me agree.

> of changing several functions.

which won't be very hard at all because any sain semaphore api will
provide atleast one of something that looks a lot like sem_init() or
a macro in the style of PTHREAD_MUTEX_INITIALIZER.

> >> 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.

1 there's nothing to be particularly careful about here, and 2 done
sainly there's no need to allocate anything in the first place.

> This semantics may require more actions than a single call sem_init or 
> sem_destroy.

sure, for doing other things than initializing semaphores or if we had a
place where we don't know at compile time how many semaphores we'll
need.  However 1 is far to general to discus usefully, and 2 isn't the
case now, if we ever need to do that we can consider some sort of
sem_creat() that allocates and initializes, but that seems a little
silly.

> 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.

a utility function that just calls one function is not really useful,
and makes the code harder to read.

> IMO, the API of SD output modules  is higher level of abstraction (relative 
> to the used libraries,  including pthread ).

I think its a stretch to call a collection of functions shared between a
couple files in the same project an api.

> Therefore, the semantics of pthread API does
> not match the semantics of the API of SD output modules.

there are plenty of places where a utility function can be seen as
usefully abstracting something, but there's nothing to abstract about
the semaphore api that doesn't create something different from a
semaphore.

> 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. 

not really unless your proposing to wrap sem_post / sem_wait to.  SInce
currently all we have is this utility function which creates a pthreads
semaphore for you and doesn't really provide any abstraction.

Trev

> This coupling makes the code of modules inflexible.
> 
>     Anatol
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20111209/f868abf9/attachment.pgp>