The active scheduler is nested.
One or more high priority active objects are started (probably several times), which all make requests on a server.
The high priority active object(s) are serviced and immediately +
The high priority active object(s) are serviced and immediately restarted. This continues until there is no more work for the high priority active object(s) to do.
The low priority active object runs and un-nests the active +
The low priority active object runs and un-nests the active scheduler.
In a single core environment, the server always processes the client requests before the client can run any other code (because the server runs @@ -442,10 +442,10 @@ to ensure all kernel memory has been cleaned up.
There are three possibilities to fix this problem:
Recreate the thread with a different name.
Wait a "little bit" before recreating the thread (or performing +
Wait a "little bit" before recreating the thread (or performing the heap check).
This is almost always a bad idea as there is no way of knowing how long to wait and this may be different on any future system.
Wait for the object concerned to be completely destroyed.
Wait for the object concerned to be completely destroyed.
In general, option 1 is preferred. For code that is likely to encounter
the problem in practice, APIs should be provided to aid with creating objects
with a unique name. For example, the