[Top][All Lists]

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

Re: coreutils vs. an LD_PRELOAD-spawned thread [Re: env

From: Harvey Eneman
Subject: Re: coreutils vs. an LD_PRELOAD-spawned thread [Re: env
Date: Thu, 22 Feb 2007 11:06:46 -0800


Thanks for the heads-up.  We're trying to be as benign as possible when loaded 
into a coreutils process.


--- Begin Message --- Subject: coreutils vs. an LD_PRELOAD-spawned thread [Re: env Date: Thu, 22 Feb 2007 18:52:52 +0100
Harvey Eneman  <address@hidden> wrote:

>> Which functions are those?
> I was referring to getenv(3), putenv(3), unsetenv(3) and setenv(3) functions.
> In my particular case, the LD_PRELOAD shared object starts a thread which
> will call getenv() but consider what could happen if the thread called
> setenv().   The env may work, produce a truncated list, or crash.

Thanks for explaining what you're doing.
As you saw, I've fixed env.c as you suggest, but you should expect more
(and more subtle!) problems if you're doing anything significant in that
thread you create: each program in the coreutils package is expected to
be run single-threaded.  In some cases, there are optimizations that
are valid only in a single-threaded environment.  One that comes to
mind is unlocked-io.h.  Here's part of that file:

/* 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.

--- End Message ---

Attachment: pgpjJuxRe971K.pgp
Description: PGP signature

reply via email to

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