pwd_grp.c: unlocked functions [PATCH]
Rob Landley
rob at landley.net
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?
Rob
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