Which LIBC version under windows!!!!
tim.one at home.com
Sat Jan 26 15:05:51 EST 2002
> I haven't kept up with threads on Unix recently, but aren't there at
> least two libc's - libc and libc_r for the re-entrant thread-safe
> functions? Presumably if you built a shared library statically linked
> to libc_r couldn't you have a similar issue to what Python has on
It varies by Unix flavor, and is definitely a problem on some. You can mine
the Python bug database for the horrid problems that result when people mix
libX and libX_r unwittingly on systems that care.
IIRC, the *real* reason to regret FILE* APIs on Windows is that they
frustrate attempts to mix code compiled under MSVC with code compiled under
other vendors' compilers (like Borland, I suppose). There may well be other
cross-vendor incompatibilities too, but incompatible FILE layouts is the one
everyone (who tries this) seems to ram into at once.
> Windows may not have a perfect solution - maybe not even close - but I
> also don't think it's a trivial problem and I'm not sure it lends
> itself to such black and white (e.g., only 1 libc allowed) solutions
> as you propose.
Yes, there are many good "go as fast as possible" reasons to stick to the
non-threaded libraries when peak speed is necessary and you don't need
threads. The tradeoffs are complex. Along the other axis, the debug-build
libraries are invaluable (particularly the MS debug malloc/free, which
routinely catch memory-management screwups in Python development that even
efence doesn't catch on Linux), but too expensive to use in production. The
MS developers aren't stupid -- they only appear to be <wink>.
More information about the Python-list