Understanding the rationale behind a rule when trying to circumvent it

In the documentation for best practices for implementing process and thread-related callback functions, it calls out

Keep routines short and simple.

Don’t make calls into a user mode service to validate the process, thread, or image.

Don’t make registry calls.

Don’t make blocking and/or Interprocess Communication (IPC) function calls.

Don’t synchronize with other threads because it can lead to reentrancy deadlocks.

So far so good. It seems that these callback functions need to operate quickly and cannot block. These are callbacks that are invoked when a process starts or exits, when a thread starts or exits, when a DLL or EXE is loaded or unloaded, and various other low-level events.

The various prohibitions above suggest that these callouts are called during the process creation/termination sequence, so if you take a long time to deal with them, you are slowing down the entire system. And the rather extreme requirements, like “Don’t make registry calls,” suggest that they might even be called while the system holds internal locks.

The list of best practices continues:

Use System Worker Threads to queue work especially work involving: Slow APIs or APIs that call into other process. Any blocking behavior that could interrupt threads in core services.

... continue reading