> I just don't understand how anyone could even consider wasting performance
> by doing a thread safe stdio via hashes to file handles. It's probably not
> much performance, and if you are lucky you would block on the found lock
> anyway, so it doesen't realy matter in the lock case. Isn't the non-blocking
> case the common path?

There are a few other implementation tricks which could be use to
preserve ABI compatibility, at the cost of some ugliness, thought I
don't think any of them are worse than doing the hash table thing, and
on the whole they'll likely be more efficient..

First of all, this all would be moot if it were not for:

#define	stdin	(&__sF[0])
#define	stdout	(&__sF[1])
#define	stderr	(&__sF[2])

in stdio.h; 

Since FILE *'s are only allocated by stdio routines, adding new fields
(like locks) to the end could be done without breaking the ABI, were
it not for this.  Anyhow, if we're going to bump the major numbers,
i'd hope we'd just make stdin/stdout/stderr visible in the ABI as
independant externals rather than elements of an array..

Anyhow, in the kludge department, we could allocate another flag bit
to indicate "out of line lock"; the standard FILE *'s in __sF would
have their locks in the corresponding __sL[] array, while other FILE
*'s could be allocated as part of a larger structure..

					- Bill