Re: gnulib and threaded execution

On 12/02/2010 04:39 PM, Paul Eggert wrote: > This should be fixable by making 'addr' auto instead of static, no? > Something like the following (untested) patch. No further comment on that, so I installed it: >From b9d6ad8aec25d6b7a01a70b7ebc0dc7c221f1cf6 Mon Sep 17 00:00:00 2001 From: Paul Egger

Re: gnulib and threaded execution

Ben Pfaff wrote: > > I would find it useful and systematic if we started to add a > > section "Multithreading:" to the module descriptions. ... > > The individual function descriptions in the manual might be a > good place to document where the thread-safety of a function > departs from that imple

Re: gnulib and threaded execution

Jim Meyering wrote: > > 2. because the alloca.c code assumes that there is a "stack > > direction". This is not the case any more with GCC's new > > "split stacks" . > > Is #2 really relevant? > alloca.c is compiled with gcc only for 1.x versions.

Re: gnulib and threaded execution

* Paul Eggert wrote on Fri, Dec 03, 2010 at 01:39:19AM CET: > On 12/02/10 13:47, Ralf Wildenhues wrote: > > > * error_at_line.c ... > > IMVHO it makes sense to at least document the requirement for the caller > > here. > > Yes. This is also a restriction for the glibc implementation, no? Yes.

Re: gnulib and threaded execution

Hi Bruno, Bruno Haible wrote: > You're just scratching the surface. More importantly, the 'alloca' > module cannot be used _at_all_ in code meant to be used in multiple > threads. > 1. because the stack size for threads is often smaller than > the stack size of the main thread. (16 KB vs. 8

Re: gnulib and threaded execution

Bruno Haible writes: > I would find it useful and systematic if we started to add a > section "Multithreading:" to the module descriptions. Its contents > could be a simple statement like "MT-safe", or a description like > this for iconv_open: > A conversion descriptor can not be used in multip

Re: gnulib and threaded execution

Hi Ralf, > When you try to use gnulib in threaded > code, any process-global state can potentially cause problems, whether > that be static data, file descriptor state, current directory, umask, > etc. For a lot of these data and in a lot of the cases, gnulib is safe. > Still, it might make sense

Re: gnulib and threaded execution

On 12/02/10 13:47, Ralf Wildenhues wrote: > * error_at_line.c ... > IMVHO it makes sense to at least document the requirement for the caller > here. Yes. This is also a restriction for the glibc implementation, no? So it's fine if gnulib has the same restriction. > * in getloadavg.c, getloadavg

gnulib and threaded execution

The recent coreutils sort bug related to threading made me take a look at gnulib for similar issues. When you try to use gnulib in threaded code, any process-global state can potentially cause problems, whether that be static data, file descriptor state, current directory, umask, etc. For a lot o