[MLton] cvs commit: sped up output1 a lot

[Jesper Louis Andersen]

Quoting Henry Cejtin (henry@sourcelight.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
> something?  

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 
non-pthread case.

> 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. 

-- 
j.