pwd_grp.c: unlocked functions [PATCH]

Rob Landley rob at
Fri Oct 7 19:45:23 UTC 2005

On Thursday 06 October 2005 22:11, Mike Frysinger wrote:
> On Thursday 06 October 2005 09:03 pm, Rob Landley wrote:
> > On Thursday 06 October 2005 16:56, Shaun Jackman wrote:
> > > This patch is required for newlib, which does not implement the glibc
> > > extensions fgets_unlocked and feof_unlocked.
> >
> > Um...  Why would anyone ever _want_ to use the _unlocked versions?  (The
> > man page doesn't say...)
> so you can poll with threads and not worry about locking ?

man fgetc_unlocked

> Each of these functions has the same behaviour as its counterpart with
> out the ‘_unlocked’ suffix, except that they do not use  locking  (they
> do  not set locks themselves, and do not test for the presence of locks
> set by others) and hence are thread-unsafe.

So you're saying people might want to use the thread _unsafe_ versions with 
threads.  Ok, I'll bite.  The libc-internal locking in the normal versions 
(which should never call back into your code, nor should your code have 
access to the libc internal locks to take them out of order) might 
conceivably screw you up how?


P.S.  I rather dislike FILE *.  It's unnecessary complexity.  It all boils 
down to a syscall anyway, and throwing in an I/O reblocking layer on the 
assumption that pathological I/O patterns are the norm is a bit silly, and 
requires you to _introduce_ gratuitous flush() calls to avoid subtle bugs so 
it's not exactly transparent anyway, is it?

More information about the busybox mailing list