[Top][All Lists]

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

[Bug-gnulib] drop unlocked-io dependency in getline module?

From: Simon Josefsson
Subject: [Bug-gnulib] drop unlocked-io dependency in getline module?
Date: Thu, 20 Nov 2003 16:01:29 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

I needed getline and noticed the module depends on the unlocked-io
module.  From unlocked-io.h:

/* Prefer faster, non-thread-safe stdio functions if available.

/* These are wrappers for functions/macros from the GNU C library, and
   from other C libraries supporting POSIX's optional thread-safe functions.

   The standard I/O functions are thread-safe.  These *_unlocked ones are
   more efficient but not thread-safe.  That they're not thread-safe is
   fine since all of the applications in this package are single threaded.

   Also, some code that is shared with the GNU C library may invoke
   the *_unlocked functions directly.  On hosts that lack those
   functions, invoke the non-thread-safe versions instead.  */

This looks like an optimization, and not a good one to use in a
library that wants to be thread safe.  Could the dependency be

Btw, I find it a bit annoying that several module depend on so many
other modules, so that often when I want a simple module (like
alloca.c) I get a lot of seemingly unrelated packages.  (alloca depend
implicitly on: alloca error exit exitfail extensions gettext malloc
realloc stdbool unlocked-io xalloc).  It would be useful to be able to
parametrize a module, so I can decide if I want, e.g., xmalloc or not
(which now many gnulib packages use).  It would be nice if each module
was more standalone.  Anyone else bothered about this?  The "malloc"
module also has a nasty side effect of redefining core C functionality
(#define malloc rpl_malloc) which break things unless I link every
library with gnulib everywhere in my package.  But I digress.

reply via email to

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