Re: Inefficient bytea escaping?

On 5/27/06, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> Given there is no way to know if you're running single threaded or not,
> I don't think glibc can take chances like that.

There's CPP symbol _REENTRANT for that and in run time,
libc can detect call to pthread_create [1].

> In any case, this isn't the issue here. Glibc doesn't do any locking
> unless pthread is linked in. Ofcourse, it takes a few cycles to
> determine that, but I don't think that'd cause a major slowdown.

You are conflicting with your previous paragraph :)

Otherwise you are right - that how a libc obviously should work, right?

http://marc.theaimsgroup.com/?l=glibc-alpha&m=100775741325472&w=2
http://marc.theaimsgroup.com/?l=glibc-alpha&m=112110641923178&w=2

I did a small test that does several fputc calls to /dev/null,
with various workarounds:

* lock.enabled is standard app.
* lock.disabled calls __fsetlocking(FSETLOCKING_BYCALLER),
as suggested by Ulrich Drepper.
* lock.unlocked calls fputc_unlocked

lock.enabled 48s
lock.disabled 28s
lock.unlocked 25s

I attached the test, you can measure yourself.

So I prepared a patch that calls __fsetlocking() in AllocateFile.
Andreas, Tom could you measure if it makes any difference?

--
marko

[1] In the first thread I linked, there was very clever
optimisation proposed using this function, that would
quarantee thread-safety even without _REENTRANT.

Unfortunately, event if U. Drepper changes his mind someday
and fixes the locking for singe-threaded apps, it would
very likely break binary compatibility with old apps,
so it wont happen in the near future.