Opened 4 years ago

Closed 9 months ago

#5 closed defect (worksforme)

WPS restart: reset SHELL semaphores for reliable operation of API "WinWaitForShell"

Reported by: erdmann Owned by:
Priority: major Milestone:
Component: component1 Version:
Keywords: Cc:

Description

using XWP 1.0.13:

there are three named event semaphores that are using by the "WinWaitForShell?" API function so that this function can block on (or being polled for) these 3 events:
Desktop created, Desktop opened, Desktop populated.

The named event semaphores are:
\SEM32\WORKPLAC\SHELL1WT.SEM (for Desktop created)
\SEM32\WORKPLAC\SHELL2WT.SEM (for Desktop opened)
\SEM32\WORKPLAC\SHELL3WT.SEM (for Desktop populated)

These 3 event semaphores are created by the 1. instance of PMSHELL.EXE but they are opened and set by the 2. instance of PMSHELL.EXE.

The problem is, that on XWP function "WPS restart", the 2. instance is just terminating thread 1 (which leads to process termination) without resetting these event semaphores. If the WPS is then restarted and an application also starting up (or the WPS) is using "WinWaitForShell?" waiting for the desktop to be created/opened/populated respectively, the "WinWaitForShell?" API call will return immediately without blocking because the event semaphores are still set. This typically leads to hang problems and the like because the WPS is typically not in the state that the application/WPS class expects it to be after returning from "WinWaitForShell?". One indication of such might be WPS classes installed via WarpIn? and requiring a WPS restart to become active where the WPS restart will lead to a system hang.

I propose to reset these 3 event semaphores shortly before the 2. instance of PMSHELL.EXE terminates its thread 1 (on a "WPS restart").

Change History (2)

comment:1 Changed 2 years ago by rlwalsh

My testing indicates that these 3 semaphores are always in a reset state when the WPS restarts.

I added code to open each and query its post count in two places: on entry to XWP in 'initMain()', and toward the end of "Restart Desktop" processing. They were always set when terminating but never set during startup. This was true regardless of whether I used the menu to restart the Desktop or I used TOP to kill it.

If you can provide a testcase, I'll be happy to look into it again. For now, though, I can't see that anything needs to be done.

comment:2 Changed 9 months ago by rlwalsh

Resolution: worksforme
Status: newclosed

Closing old ticket - no further actions needed.

Note: See TracTickets for help on using tickets.