This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> > I have never been in favor of a per-thread ID extension. > > They definitely want to preserve this and therefore any kernel solution > is as nonatomic as the userlevel implementation. (not my analysis). Like I said, they haven't been presented with an implementation yet. What I would propose would allow such an extension and also implement correct semantics when you are not using it. It's pointless to speculate about what others would or wouldn't say in circumstances that don't exist yet. > I think this is as good as we'll get it any time soon (or ever). Assuming you are talking about the simulation of almost correct semantics, that may be. My point about that was that we should make sure that people are aware of the "almost" and what it means. You did not respond at all to my objection to your glibc extension functions. Please say something about how you intend these to be acceptable features. As they stand, it's necessary for me to absolutely refuse to cooperate with their inclusion in glibc, and warn people away from using nscd as it is. Let's talk about what features we really do want, and about getting them fully specified and securely implemented. Thanks, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |