I'm looking for the start of a review *and testing* of the new locale bits I've developed in support of the new POSIX standards for thread-specific locales. (This is part of POSIX 2008.) I think this stuff is not far from being ready for prime time.
I've been able to boot the new bits, and initial tests so far seem promising. I've not observed any *obvious* problems. Additionally, I've verified (using a rather trivial C program) that the library now supports multithreaded programs where each thread can optionally operate in a separate locale. This should support building newer programs which depend on the presence of newlocale(), uselocale() etc. Note that there are some bits here still missing. The support for memory streams (open_memstream()) is absent for example. But this is a huge step towards completion of POSIX 2008 support, I believe. The work is available here: https://bitbucket.org/gdamore/illumos-gate/commits/branch/newlocale (Note that this is a full branch -- you'll want to collapse the branch before final integration.) Feel free to make a fork of this and build it, and onu it. It does seem to work fine at least for me within an OpenIndiana 151a8 environment. Testing so far has been limited though. The webrev is here: http://cr.illumos.org/~gdamore/newlocale/ This is a *huge* chunk to review -- some 4614 lines of change according to webrev. Some things I'm not 100% certain about: 1. Performance - this implementation uses thread-specific data for locale data, and as a result hits that data on some hot code paths. This could have a performance impact for uses of the printf family, as well as strxfrm (or strcoll) and most especially the ctype classification stuff. Most other locale oriented functions are unlikely to be hot. (Do you use printf / sprintf in hot code paths?) For the record, I have an idea to accelerate the C locale somewhat, but it involves adding a function pointer reference. Opinions for measuring this, and real world impacts, are desired. 2. Mix with legacy code (libraries) and new code. If a library calls setlocale() -- I think this is safe. But old code won't automatically inherit new behaviors -- in particular if the ctype macros baked in references to fixed structures that I can't make thread aware. If you've got such legacy libraries, don't expect them to automagically start working well with threaded programs that use uselocale() and friends. They need to be rebuilt. (Again, the character classification stuff in ctype.h is most likely to be of concern.) 3. C++ interfaces. I'm not sure I got this stuff right. I don't really understand C++ anymore, so I'd like someone with more expert knowledge here -- particularly of the proper namespacing, etc. to review it. I'm also keen to make sure that I've not busted any C++ ABIs. 4. ABI compatibility in general. I'm pretty sure I got this right but I'd like expert review. 5. POSIX conformance. POSIX-ifarians, please critique this harshly -- but do include specific details where I've got it wrong, and suggestions how to make it better. 6. SPARC. There are SPARC bits here. I think I got them right. I haven't tested. If you care about this on SPARC, *please* give it a shot and tell me about any shortcomings! Sadly, I've not gotten around to writing man pages for all the new routines. I was actually thinking of asking the Open Group to give us a license to use their content. They had done so for Sun previously. It would substantially reduce my effort. If anyone from TOG is reading this, please contact me! :-) Thanks everyone, and enjoy! I really really hope for constructive reviews, and useful test reports! - Garrett ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
