XtimeScheduler XtimeCreateScheduler(Display *display, XtimeClock clock);
void XtimeFreeScheduler(Display *display, XtimeScheduler scheduler);
XtimeGroup *XtimeBegin(Display * display , XtimeScheduler scheduler, XtimeGroupID id , uint32_t begin , uint32_t end );
XtimeGroup *XtimeBeginReplace(Display * display , XtimeScheduler scheduler , XtimeGroupID id );
int XtimeGroupSetNotification(XtimeGroup * group , unsigned int notify );
int XtimeEnd(XtimeGroup * group);
void XtimeAbort(XtimeGroup * group);
void XtimeCancelGroup(Display * display , XtimeScheduler scheduler , XtimeGroupID group);
Schedulers support execution of X requests on behalf of the client at defined points in time. The scheduler will use the clock given at creation time to determine when to perform operations. Operations are submitted as groups of requests with a validity interval [begin,end) - the operations will be performed no earlier than begin and no later than end (with preference to the beginning of the interval), and they may not be executed at all if the server does not have sufficient processing resources within the time interval. Either all requests in group are executed, or none is.
All groups submitted to the same scheduler are considered in the order of their begin timestamp. At any given point in time the scheduler considers the first group and decides to execute or drop it depending on its end timestamp before moving on to the next group. Thus all groups submitted to the same scheduler are strictly serialized, the scheduler will never "interleave" requests from two different groups. This does however not mean that execution of a group is atomic with respect to requests submitted to other schedulers, by other clients or even the client on behalf of which the scheduler is executing.
Applications can construct groups of requests by first calling XtimeBegin, followed by zero or more functions that add requests to the group, followed by a call to XtimeEnd to submit the constructed group of requests. The application may elect not to submit the group it has just constructed by calling the XtimeAbort function.
Applications can request a notification if a group is being processed by calling the XtimeGroupSetNotification function; the notify parameter may be a bitwise or of XtimeNotifyExecute and XtimeNotifyDropped - this will cause the server to send an XtimeGroupEvent if the group has been executed or not executed due to insufficient resources, respectively. The event informs the client about the status of the group and also contains a timestamp of the instant the event was generated. Clients may therefore submit empty groups of requests with just the notification flags set to periodically receive time information about a clock.
The function XtimeCancelGroup allows applications to cancel a previously scheduled group of requests. The group identified by the given id will not be executed afterwards. Note: The function will do nothing if the group cannot be cancelled because it has been executed already or execution is in progress - the client will not receive an error message in this case. Since the scheduler does not distinguis between group ids that correspond to executed groups and group iFids that have never been used it is also not an error to cancel groups that have never been submitted.
Applications may also replace the set of requests of a previously submitted group by first calling XtimeBeginReplace, followed by zero or more functions tha add requests to the group, followed by a call to XtimeEnd to submit the replacement requests. The notes from the previous section apply here as well.