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