Re: [PATCH] use unlocked stdio functions
On 2/5/24 10:47 PM, Grisha Levit wrote: Bash makes many calls to stdio functions that may have unlocked_stdio(3) equivalents. Since the locking functionality provided by the regular versions is only useful in multi-threaded applications, it probably makes sense for Bash to use the *_unlocked versions where available. Thanks for the patch; this looks like a great idea. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] use unlocked stdio functions
On Wed, Feb 14, 2024 at 10:59:57AM -0500, Chet Ramey wrote: > On 2/5/24 10:47 PM, Grisha Levit wrote: > > Bash makes many calls to stdio functions that may have unlocked_stdio(3) > > equivalents. Since the locking functionality provided by the regular > > versions is only useful in multi-threaded applications, it probably makes > > sense for Bash to use the *_unlocked versions where available. > > Thanks for the patch; this looks like a great idea. > I thought this was only necessary for C programs built with pthreads linked in / -D_REENTRANT. Is that no longer the case? Or has bash started making use of pthreads? When I first learned pthreads ages ago there was a substantial performance hit to the classical stdio-using programs when you built them w/pthreads. It was an important detail to be aware of at the time because so many programs of the era had been written assuming things like getc/ungetc and other character-granular stdio functions were fast functions if not macros. But you didn't incur this hit if you didn't make use of pthreads, which seemed like a conscious choice of the pthreads creators to not impact all such existing software just because a platform added pthreads support. So unless my understanding is wrong/stale or bash has started using pthreads, I don't think this should be necessary. But things do seem to have evolved here; for instance we no longer explicitly add -D_REENTRANT with gcc, instead using -pthread now. Would appreciate any input on the current state of things in this area... Thanks, Vito Caputo
Re: [PATCH] use unlocked stdio functions
On 2/14/24 11:18 AM, Vito Caputo wrote: On Wed, Feb 14, 2024 at 10:59:57AM -0500, Chet Ramey wrote: On 2/5/24 10:47 PM, Grisha Levit wrote: Bash makes many calls to stdio functions that may have unlocked_stdio(3) equivalents. Since the locking functionality provided by the regular versions is only useful in multi-threaded applications, it probably makes sense for Bash to use the *_unlocked versions where available. Thanks for the patch; this looks like a great idea. I thought this was only necessary for C programs built with pthreads linked in / -D_REENTRANT. Is that no longer the case? Or has bash started making use of pthreads? It's more like the opposite: the stdio functions provided by glibc and other versions of the standard C library are thread-safe by default, so multi-threaded programs don't have to do anything. They're ok for non- threaded programs, too, except that those programs have to absorb the locking overhead. If you are sure that your program doesn't need the thread-safe functions, which basically work by locking FILE * objects so only one thread can use and modify them at a time (see flockfile(3)), you can use the unlocked versions. Most of the time, the lock overhead is small. But for some usage patterns, it can be significant. These functions are defined by POSIX as part of the base system: https://pubs.opengroup.org/onlinepubs/9699919799/functions/getc_unlocked.html#tag_16_188 They didn't used to be part of the base standard. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix minor portability issues including ISO C 23 prototypes.
On 2/14/24 12:26 AM, Collin Funk wrote: Hi, I noticed some compiler warnings that might be worth fixing. I wasn't sure if patches should have ChangeLog entries so I left it alone and tried to make it easy to copy paste for you. Feel free to use or ignore changes as you see fit. Thanks for the patches. * lib/sh/getenv.c (getenv, putenv, setenv, unsetenv): Don't assume that NULL is equivalent to 0 and just use the macro itself. This isn't necessary in general; ISO C guarantees that a constant expression with value 0 is a null pointer constant just like NULL, and the compiler will make them equivalent even if the internal representation of a null pointer isn't all zeroes. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Fix minor portability issues including ISO C 23 prototypes.
On 2/14/24 11:56 AM, Chet Ramey wrote: > This isn't necessary in general; ISO C guarantees that a constant > expression with value 0 is a null pointer constant just like NULL, > and the compiler will make them equivalent even if the internal > representation of a null pointer isn't all zeroes. Oops, You're right. That's my bad. I think I saw a compiler for the first comparison to zero in setenv () which is right above a NULL return. I think the NULL looks more clear but that is probably just personal preference. :) Collin
