pwd_grp.c: unlocked functions [PATCH]
Rob Landley
rob at landley.net
Fri Oct 7 22:51:50 UTC 2005
On Friday 07 October 2005 16:25, Shaun Jackman wrote:
> 2005/10/7, Rob Landley <rob at landley.net>:
> > 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?
>
> Each putc call requires a mutex lock and unlock. If that's in an inner
> loop, it could hamper performance. putc_unlocked allows you to move
> the locking outside of the loop.
Since when is doing your own block assembly (via interatively filling a char
buffer before calling write) brain surgery? Busybox does it all the time.
Look at editors/sed.c lines 579-594, or
archival/libunarchive/decompress_bunzip2.c line 460.
Heck, look at tee.c where we have to call a function to _disable_ the FILE *
output buffering (lines 74 and 96), working around the infrastructure we
chose to use.
> > 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?
>
> The syscall write(1, &c, 1) is far more heavyweight than putchar(c),
> which boils down to *stdout->p++ = c.
Sure. But doing *p++=c by hand when we actually care isn't hard, and is what
we generally wind up doing rather than messing around with the guts of FILE
*.
> Cheers,
> Shaun
Rob
More information about the busybox
mailing list