Re: Lock module improvement

[Bruno Haible]

Hi Yoann,

Yoann Vandoorselaere wrote:
> > I think you can effectively already do it. Like this:
> > 
> >   gl_LOCK
> >   if test $gl_threads_api = pth; then
> >     AC_FATAL([The pth threads implementation is not supported by this 
> > package.])
> >   fi
> 
> Thanks! Wouldn't it be better to directly provide support for a given
> backend to be disabled (so that configure doesn't export un-supported
> option)?

The benefit is so tiny that I won't spend time on it. But if you have time
for this, show your patch.

> > > - Implement support for condition variable.
> > 
> > You are welcome to contribute a module for this.
> 
> I started working on condition variable support. To me, it make sense to
> do that directly within the lock module (the code is very much similar
> to what currently exist for mutex primitive). Any objection?

Yes, I continue to think that it belongs into a different module, because

  1) For 95% of all multithread programming, all one needs is
       - locks,
       - thread-local storage,
       - starting and joining threads.
     Wait queues and condition variables are less needed and harder to
     use correctly (without introducing bugs or deadlocks).

  2) The 'lock' module is compiled into libintl, and therefore I prefer to
     avoid increasing its .o file size for things that libintl does not need.

Bruno