On 10/12/2012 10:25 AM, Ehsan Akhgari wrote:
Do we require to maintain source or binary compatibility, or both?
Also, is it acceptable for us to add new preprocessor definitions such
as NO_NSPR_10_SUPPORT to optionally remove some of the NSPR feature
which we would like Gecko to avoid, without changing the default set
of names declared in NSPR headers?
Technically both. NSPR is a system library that is guaranteed to be
backwards compatible until you change the ABI version, which never happens.
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.
Both xpcom/ds and MFBT are basically workarounds for this problem. I
think that in general the best thing to do here is stop depending on
NSPR when it doesn't suit us and fork/reimplement things in MFBT/XPCOM.
Eventually we may not need NSPR at all, or may need it only because NSS
has a dependency on it. The API design of things like mozilla::Mutex is
specifically to help that goal: if we get everyone using Mutex, then we
can switch out the implementation under the hood without massive
refactoring of the entire codebase.
Another issue which I think sometimes prevents us from fixing things
in NSPR is that the process usually looks like submitting the patch to
NSPR, getting it reviewed, then wait until the next NSPR release
(which we don't know when will happen), then import the new release
into mozilla-central. This usually involves an amount of time which
may not be acceptable in our new 6-week cycles, which I believe is
sometimes the reason why people don't even bother submitting NSPR
patches in the first place and just resort to working around the
problem (which is painful in a lot of cases.) If there is anything
that can be done in order to streamline this process, it would be great!
Basically all the Linux distributions compile their Firefox against the
system NSPR and NSS. This means that if we make local patches to NSPR,
those won't be reflected in any of the versions that ship to most Linux
users unless we also upstream the change and get it to the distros in time.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
