This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: last call


> >That's not true.  It simply opens a can of worms.
> 
> Besides, it's completely nonstandard.  If we wanted to have this option, we
> ought to default to xxx_unlocked and require you #define _REENTRANT to get
> the locking versions.  (This is how Solaris, Irix, etc. do it.)

I suggested it before. But people think glibc should be thread safe
by default, which I agree. I am concerned about the big single
threaded applications. Replacing with the unlocked versions is not
that practical. I'd like to have a switch to use those unlocked
versions by default. It will help transition to glibc without hurting
performance.

> 
> But there are better ways to do it: we could put unlocked stdio entrypoints
> in libc and override them with locking versions in libpthread, or we could
> simply reduce the overhead of the locking versions in the no-thread case (I
> think we already do something like this with inline functions).
> 
> 

Those unlocked versions are just macros.


-- 
H.J. Lu (hjl@gnu.org)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]