On 2012-10-14 6:57 PM, Robert O'Callahan wrote:
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari <[email protected] <mailto:[email protected]>> wrote:In some cases in the past (such as bug 563082), we've needed to change the semantics of some of the NSPR functions to make them work better for some things, such as more precise time measurements, but we've had to implement our own APIs (e.g., http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/TimeStamp_windows.cpp) which we've since heavily optimized (for example, in bug 784859). Would such improvements be interesting to NSPR? I guess in a lot of cases we just don't know whether NSPR would accept a patch if we make one, so we end up implementing our own APIs. One thing is that most of our new library APIs tend to be C++ and NSPR is a C library. I don't think we would want to restrict new APIs to C just so they could be folded into NSPR. (TimeStamp and Mutex, for example, really benefit from being C++ APIs.)
Sure, I was not suggesting that. What I was suggesting was to take our implementation of the TimeStamp class for Windows and use the same ideas in the NSPR implementation of that function, for callers who prefer to use the PRTime API.
Ehsan _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
