Re: support for multithread-safe libraries

[Bruno Haible]

Paul Eggert wrote:
> The word "lock" is good, but (unfortunately) lots of things are
> locked, and there are different forms of locks.  Files can be locked
> with flock, for example.  "lock.h" could refer to any of these things.

"flock" and "lockf" are the common names of that.

> > and resembles glibc's <bits/libc-lock.h>.
>
> If the module is based on gcc/gthr.h but does only locks, how about
> the name "gthr-lock"?

The lock.* code is so distant from gcc's gthr.h by now that it would be
highly confusing to mention it in the name:
  - gthr.h defines __gthread_* functions, whereas lock.h defines gl_*
    functions.
  - gthr.h names them "mutex", whereas lock.h names them just "lock"
    (because for some people, a "mutex" is an inter-process communication
    mechanism as well),
  - gthr.h does not have read/write locks,
  - gthr.h has *_trylock functions,
  - The Win32 port of gthr.h's locks is based on CreateMutex, and its
    recursive locks are based on CreateSemaphore, whereas in my lock.h
    they are based on CRITICAL_SECTION, which are more lightweight (not
    suitable for inter-process communication, can't be waited for, doesn't
    have a handle).

So I still think the name "lock" is fine.

Bruno