Opened 7 years ago
Closed 7 years ago
#166 closed task (fixed)
nspr: Use WinWaitEventSem instead of DosWaitEventSem
Reported by: | dmik | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | nspr | Version: | |
Severity: | medium | Keywords: | |
Cc: | dryeo |
Description
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.
Change History (4)
comment:1 by , 7 years ago
Cc: | added |
---|
comment:2 by , 7 years ago
comment:3 by , 7 years ago
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.
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.