[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lock module improvement

From: Bruno Haible
Subject: Re: Lock module improvement
Date: Tue, 22 Jul 2008 01:44:39 +0200
User-agent: KMail/1.5.4

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]