Defines a procedure that is to be called by the Asynchronous Scheduler (AES) after a specified delay
#include <nwthread.h>
extern void ScheduleSleepAESProcessEvent (
struct AESProcessStructure *EventNode);
(IN) Points to the AESProcessStructure, which defines the event.
The defined procedure can go to sleep when it runs. The event is called at process time.
The AESProcessStructure is defined as follows:
struct AESProcessStructure
{
struct AESProcessStructure *ALink; /*Set by AES*/
LONG AWakeUpDelayAmount; /*Set to # ticks to
wait*/
LONG AWakeUpTime; /*Set by AES*/
void (*AProcessToCall) (void *); /*Set to function to
call*/
LONG ARTag; /*Set to resource tag */
LONG AOldLink; /*Set to NULL*/
}
Fields that are not set by AES must be set by the user as specified in the above structure definition.
When the defined procedure is called, the AESProcessStructure pointer is passed to it as the only parameter. By adding fields to the end of the structure, the user can pass information to the procedure.
If the event procedure reschedules itself, the function can be made to execute periodically. The scheduled event can be cancelled before time is up by calling CancelSleepAESProcessEvent.
The procedure registered by ScheduleSleepAESProcessEvent runs as a callback (an OS Thread), which is not able to call most of the NetWare API functions, unless it is given CLIB context.
For 3.11 NLM applications, you must manually create the thread group context in your procedure, by calling SetThreadGroupID and passing a valid thread group ID. Before this thread returns, it should reset its context to its original context, by setting the thread group ID back to its original value.
For 4.x, 5.x, and 6.x NLM applications, the context that is given to the callbacks when they are registered is determined by the value in the registering thread’s context specifier. You can set the context specifier to one of the following options:
NO_CONTEXT-Callbacks registered with this option are not given CLIB context. The advantage here is that you avoid the overhead needed for setting up CLIB context. The disadvantage is that without the context the callback is only able to call NetWare API functions that manipulate data or manage local semaphores.
Once inside of your callback, you can manually give your callback thread CLIB context by calling SetThreadGroupID and passing in a valid thread group ID. If you manually set up your context, you need to reset its context to its original context, by setting the thread group ID back to its original value.
USE_CURRENT_CONTEXT-Callbacks registered with a thread that has its context specifier set to USE_CURRENT_CONTEXT have the thread group context of the registering thread.
A valid thread group ID-This is to be used when you want the callbacks to have a different thread group context than the thread that schedules them.
When a new thread is started with BeginThread, BeginThreadGroup or ScheduleWorkToDo, its context specifier is set to USE_CURRENT_CONTEXT by default.
You can determine the current setting of the registering thread’s context specifier by calling GetThreadContextSpecifier. Use SetThreadContextSpecifier to set the registering thread’s context specifier to one of the above options.
For more information on using CLIB context, see Context Problems with OS Threads (NDK: NLM Threads Management).