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 dryeo, 7 years ago

Cc: dryeo added

comment:2 by Steven Levine, 7 years ago

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.

comment:3 by dmik, 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.

comment:4 by dmik, 7 years ago

Resolution: fixed
Status: newclosed

Done in r2209.

Note: See TracTickets for help on using tickets.