[MLton] cvs commit: sped up output1 a lot
Jesper Louis Andersen
Sat, 3 Jan 2004 01:20:03 +0100
Quoting Henry Cejtin (email@example.com):
> I don't see how it is arranged to make putc be the non-locked version. The
> point is that you can make the function which is called be the same (by
> clever library ordering) but you can't convert it into a macro. The compiler
> can't know when it compiles some code if it is going to be linked with thread
> producing code.
I think you are getting all of it and we are just misunderstanding each other.
NetBSD has an internal call in /usr/include/stdio.h which is named __sput(). By
#defines this is linked to putc() and putc_unlocked() if none of the defines
RE_ENTRANT or PTHREAD is set. In the case where you are compiling threaded code
you are bound to use gcc -pthread, which links against libc_r instead of libc.
It does also set PTHREAD as far as I remember. This effectively means we in
that case get the libc_r version instead of the macro in the header file.
> Don't get me wrong, I think that making getc/putc run slowly in the non-
> thread case is unacceptable, but I don't see a solution. Am I missing
I dont think you miss anything. I dont think the above is completely correct
with respect to POSIX either. The point is that posix explictly define that
putc() is locked and as far as I can see, NetBSD does not lock it in the
> Re system calls being expensive, I would be really surprised if they are so
> expensive that switching from a 4K BUFSIZ to a 64K one really makes any
> appreciable difference. We could switch that though.
I am pretty sure this is not the problem either.