946841 - Offer an alternative to NSPR when building the shell on Windows platforms

Status: RESOLVED DUPLICATE of bug 956899

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

+++ This bug was initially created as a clone of Bug #931151 +++

Since --enable-posix-nspr-emulation works for POSIX platforms, we should consider this for Windows platforms too.

This allows us to consolidate harness compilation parameters across remaining platforms for the fuzzers by making it easier to compile threadsafe builds.

Bill, how feasible is this?

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I talked to Terrence and it's actually tricky. WinXP doesn't support condition variables, and emulating them is hard. How useful do you think it would be to have this for Win7 and above?

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> How useful do you think it would be to have this for Win7 and above?

Very useful, assuming WinXP is end-of-life'd (we'd have to wait for support for this to go away).

We can then stop compiling NSPR for the particular revision of m-c in order to (largely) get a successful threadsafe shell, saving code complexity, compile time and eventually bisection times.

(well, either this or fixing bug 720018 might be another way forward)

Comment 3

[(no longer active)]

Can't you emulate a condition variable using a semaphore?

Comment 4

[Jason Orendorff [:jorendorff]]

Or an event (CreateEvent/SetEvent/ResetEvent/PulseEvent). Yes.

Comment 5

[Luke Wagner [:luke]]

I was curious earlier and it seems like it's rather difficult to get a high-fidelity condvar from these primitives:
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

Maybe we don't need a high-fidelity condvar, though?

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Yes, Terrence pointed me to that link as well. However, now that I read it over more carefully, I think it's way too persnickety. First it considers one obviously wrong implementation and fixes it. But then it tries to show that the fixed implementation violates various fairness conditions that don't seem important to me. I think we should be able to adopt the approach in section 3.2 of that document, which isn't too tricky.

I don't have time to do this now, but maybe in a couple weeks.

Comment 7

[Terrence Cole [:terrence]]

And this has been done in bug 956899. It is still waiting on the contributor to have some free time to land it, but it is a complete and working implementation of this idea.