nspr: Use WinWaitEventSem instead of DosWaitEventSem

[dmik]

There is some code that uses DosWaitEventSem. In particular, PR_WaitCondVar. Using PR_WaitCondVar in a GUI thread of a PM app will effectively block not only this app but the whole PM due to the SMQ (single message queue) syndrome. See ​https://github.com/bitwiseworks/mozilla-os2/issues/225 for a real life example.

Using WinWaitEventSem instead of DosWaitEventSem fixes the problem and makes PR_WaitCondVar PM-friendly. However, this brings a dependency on PMWIN.DLL to NSPR4.DLL which will make it impossible to use apps linked against NSPR4.DLL in a PM-less environment (i.e. when CMD.EXE or another application is used as a protmode shell instead of PMSHELL.EXE and PMWIN.DLL is not available at all).

To avoid this, we should load WinWaitEventSem dynamically and use DosWaitEventSem as a fallback.

[Steven Levine]

Using WinWaitEventSem? only if the entrypoint is accessible should be a relatively easy solution. I got sufficiently curious to see what WinWaitEventSem? does beyond what the docs claim. The good news is that if called for a thread without a message queue, it invokes DosWaitEventsum?. This makes the API less messy to use.

[dmik]

Steven, yes, this is what I'm going to do. And I actually was pretty sure that WinWaitEventSem checks for a queue and falls back to DosWaitEventSem if there is none so I decided to not do it myself to avoid extra dependencies. But it's always good to know for sure, so thanks for checking it out.

[dmik]

Done in r2209.