[Top][All Lists]

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

Re: read-write locks

From: Torvald Riegel
Subject: Re: read-write locks
Date: Fri, 06 Jan 2017 15:52:30 +0100

On Fri, 2017-01-06 at 15:08 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > What are the rwlock users, actually?  A web search for gl_rwlock_t seems
> > to only turn up lock.h, but no users (unlike gl_lock_t, for example).
> You're right, there are no users so far. But there may be in the future:

So we're spending all this time here on something that has no users, and
it's wasting the time of developers in other projects because the tests
are questionable?
Just remove it and revive it when there are actual users, please.  And
then just use the C++ reader-writer lock semantics.

> Gnulib occasionally grabs some piece of code from glibc and makes it available
> on non-glibc systems.
> Many of the gnulib modules need to be multithread-safe. (For example, module
> 'fstrcmp' needs to be, because GNU gettext invokes it from within an OpenMP-
> parallelized region.)
> glibc uses an internal API <libc-lock.h> for its locking. It defines normal
> locks, rwlocks, recursive locks, and once-only control. Since this is what
> glibc code needs, in general, this is what the gnulib module 'lock' provides.

This is internal to glibc.  How one derive a need to expose any of this
externally is unclear to me.

> And the test-lock.c code tests it, because it is good practice, in gnulib,
> to provide unit tests.

It tests for feature that glibc does not provide.

reply via email to

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