diff options
Diffstat (limited to 'doc/Notifier.3')
| -rw-r--r-- | doc/Notifier.3 | 137 |
1 files changed, 98 insertions, 39 deletions
diff --git a/doc/Notifier.3 b/doc/Notifier.3 index 7776610..f2976b1 100644 --- a/doc/Notifier.3 +++ b/doc/Notifier.3 @@ -5,13 +5,11 @@ '\" See the file "license.terms" for information on usage and redistribution '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. '\" -'\" RCS: @(#) $Id: Notifier.3,v 1.15 2005/05/10 18:33:56 kennykb Exp $ -'\" -.so man.macros .TH Notifier 3 8.1 Tcl "Tcl Library Procedures" +.so man.macros .BS .SH NAME -Tcl_CreateEventSource, Tcl_DeleteEventSource, Tcl_SetMaxBlockTime, Tcl_QueueEvent, Tcl_ThreadQueueEvent, Tcl_ThreadAlert, Tcl_GetCurrentThread, Tcl_DeleteEvents, Tcl_InitNotifier, Tcl_FinalizeNotifier, Tcl_WaitForEvent, Tcl_AlertNotifier, Tcl_SetTimer, Tcl_ServiceAll, Tcl_ServiceEvent, Tcl_GetServiceMode, Tcl_SetServiceMode \- the event queue and notifier interfaces +Tcl_CreateEventSource, Tcl_DeleteEventSource, Tcl_SetMaxBlockTime, Tcl_QueueEvent, Tcl_ThreadQueueEvent, Tcl_ThreadAlert, Tcl_GetCurrentThread, Tcl_DeleteEvents, Tcl_InitNotifier, Tcl_FinalizeNotifier, Tcl_WaitForEvent, Tcl_AlertNotifier, Tcl_SetTimer, Tcl_ServiceAll, Tcl_ServiceEvent, Tcl_GetServiceMode, Tcl_SetServiceMode, Tcl_ServiceModeHook, Tcl_SetNotifier \- the event queue and notifier interfaces .SH SYNOPSIS .nf \fB#include <tcl.h>\fR @@ -66,9 +64,14 @@ int .sp int \fBTcl_SetServiceMode\fR(\fImode\fR) - +.sp +void +\fBTcl_ServiceModeHook\fR(\fImode\fR) +.sp +void +\fBTcl_SetNotifier\fR(\fInotifierProcPtr\fR) .SH ARGUMENTS -.AS Tcl_EventDeleteProc *deleteProc +.AS Tcl_EventDeleteProc *notifierProcPtr .AP Tcl_EventSetupProc *setupProc in Procedure to invoke to prepare for event wait in \fBTcl_DoOneEvent\fR. .AP Tcl_EventCheckProc *checkProc in @@ -78,7 +81,7 @@ queues them. .AP ClientData clientData in Arbitrary one-word value to pass to \fIsetupProc\fR, \fIcheckProc\fR, or \fIdeleteProc\fR. -.AP Tcl_Time *timePtr in +.AP "const Tcl_Time" *timePtr in Indicates the maximum amount of time to wait for an event. This is specified as an interval (how long to wait), not an absolute time (when to wakeup). If the pointer passed to \fBTcl_WaitForEvent\fR @@ -100,8 +103,11 @@ passed to \fBTcl_DoOneEvent\fR. .AP int mode in Indicates whether events should be serviced by \fBTcl_ServiceAll\fR. Must be one of \fBTCL_SERVICE_NONE\fR or \fBTCL_SERVICE_ALL\fR. +.AP Tcl_NotifierProcs* notifierProcPtr in +Structure of function pointers describing notifier procedures that are +to replace the ones installed in the executable. See +\fBREPLACING THE NOTIFIER\fR for details. .BE - .SH INTRODUCTION .PP The interfaces described here are used to customize the Tcl event @@ -208,7 +214,6 @@ return. .IP [7] Either return 0 to indicate that no events were ready, or go back to step [2] if blocking was requested by the caller. - .SH "CREATING A NEW EVENT SOURCE" .PP An event source consists of three procedures invoked by the notifier, @@ -222,11 +227,13 @@ The procedure \fBTcl_CreateEventSource\fR creates a new event source. Its arguments specify the setup procedure and check procedure for the event source. \fISetupProc\fR should match the following prototype: +.PP .CS -typedef void Tcl_EventSetupProc( +typedef void \fBTcl_EventSetupProc\fR( ClientData \fIclientData\fR, int \fIflags\fR); .CE +.PP The \fIclientData\fR argument will be the same as the \fIclientData\fR argument to \fBTcl_CreateEventSource\fR; it is typically used to point to private information managed by the event source. @@ -234,7 +241,7 @@ The \fIflags\fR argument will be the same as the \fIflags\fR argument passed to \fBTcl_DoOneEvent\fR except that it will never be 0 (\fBTcl_DoOneEvent\fR replaces 0 with \fBTCL_ALL_EVENTS\fR). \fIFlags\fR indicates what kinds of events should be considered; -if the bit corresponding to this event source isn't set, the event +if the bit corresponding to this event source is not set, the event source should return immediately without doing anything. For example, the file event source checks for the \fBTCL_FILE_EVENTS\fR bit. @@ -261,12 +268,14 @@ connection. The \fItimePtr\fR argument to \fBTcl_WaitForEvent\fR points to a structure that describes a time interval in seconds and microseconds: +.PP .CS typedef struct Tcl_Time { - long \fIsec\fR; - long \fIusec\fR; -} Tcl_Time; + long \fIsec\fR; + long \fIusec\fR; +} \fBTcl_Time\fR; .CE +.PP The \fIusec\fR field should be less than 1000000. .PP Information provided to \fBTcl_SetMaxBlockTime\fR @@ -296,11 +305,13 @@ The second procedure provided by each event source is its check procedure, indicated by the \fIcheckProc\fR argument to \fBTcl_CreateEventSource\fR. \fICheckProc\fR must match the following prototype: +.PP .CS -typedef void Tcl_EventCheckProc( +typedef void \fBTcl_EventCheckProc\fR( ClientData \fIclientData\fR, int \fIflags\fR); .CE +.PP The arguments to this procedure are the same as those for \fIsetupProc\fR. \fBCheckProc\fR is invoked by \fBTcl_DoOneEvent\fR after it has waited for events. Presumably at least one event source is now prepared to @@ -319,12 +330,14 @@ to that event source. However, the first element of the structure must be a structure of type \fBTcl_Event\fR, and the address of this structure is used when communicating between the event source and the rest of the notifier. A \fBTcl_Event\fR has the following definition: +.PP .CS typedef struct { Tcl_EventProc *\fIproc\fR; struct Tcl_Event *\fInextPtr\fR; -} Tcl_Event; +} \fBTcl_Event\fR; .CE +.PP The event source must fill in the \fIproc\fR field of the event before calling \fBTcl_QueueEvent\fR. The \fInextPtr\fR is used to link together the events in the queue @@ -352,11 +365,13 @@ When it is time to handle an event from the queue (steps 1 and 4 above) \fBTcl_ServiceEvent\fR will invoke the \fIproc\fR specified in the first queued \fBTcl_Event\fR structure. \fIProc\fR must match the following prototype: +.PP .CS -typedef int Tcl_EventProc( +typedef int \fBTcl_EventProc\fR( Tcl_Event *\fIevPtr\fR, int \fIflags\fR); .CE +.PP The first argument to \fIproc\fR is a pointer to the event, which will be the same as the first argument to the \fBTcl_QueueEvent\fR call that added the event to the queue. @@ -376,7 +391,7 @@ There are several reasons why an event source might defer an event. One possibility is that events of this type are excluded by the \fIflags\fR argument. For example, the file event source will always return 0 if the -\fBTCL_FILE_EVENTS\fR bit isn't set in \fIflags\fR. +\fBTCL_FILE_EVENTS\fR bit is not set in \fIflags\fR. Another example of deferring events happens in Tk if \fBTk_RestrictEvents\fR has been invoked to defer certain kinds of window events. @@ -396,23 +411,26 @@ an event to the current thread's queue. To add an event to another thread's queue, use \fBTcl_ThreadQueueEvent\fR. \fBTcl_ThreadQueueEvent\fR accepts as an argument a Tcl_ThreadId argument, which uniquely identifies a thread in a Tcl application. To obtain the -Tcl_ThreadID for the current thread, use the \fBTcl_GetCurrentThread\fR +Tcl_ThreadId for the current thread, use the \fBTcl_GetCurrentThread\fR procedure. (A thread would then need to pass this identifier to other threads for those threads to be able to add events to its queue.) After adding an event to another thread's queue, you then typically -need to call \fBTcl_ThreadAlert\fR to "wake up" that thread's notifier to -alert it to the new event. +need to call \fBTcl_ThreadAlert\fR to +.QW "wake up" +that thread's notifier to alert it to the new event. .PP \fBTcl_DeleteEvents\fR can be used to explicitly remove one or more events from the event queue. \fBTcl_DeleteEvents\fR calls \fIproc\fR for each event in the queue, deleting those for with the procedure returns 1. Events for which the procedure returns 0 are left in the queue. \fIProc\fR should match the following prototype: +.PP .CS -typedef int Tcl_EventDeleteProc( +typedef int \fBTcl_EventDeleteProc\fR( Tcl_Event *\fIevPtr\fR, ClientData \fIclientData\fR); .CE +.PP The \fIclientData\fR argument will be the same as the \fIclientData\fR argument to \fBTcl_DeleteEvents\fR; it is typically used to point to private information managed by the event source. The \fIevPtr\fR will @@ -422,7 +440,6 @@ point to the next event in the queue. \fIcheckProc\fR, and \fIclientData\fR arguments must exactly match those provided to the \fBTcl_CreateEventSource\fR for the event source to be deleted. If no such source exists, \fBTcl_DeleteEventSource\fR has no effect. - .SH "CREATING A NEW NOTIFIER" .PP The notifier consists of all the procedures described in this manual @@ -430,13 +447,13 @@ entry, plus \fBTcl_DoOneEvent\fR and \fBTcl_Sleep\fR, which are available on all platforms, and \fBTcl_CreateFileHandler\fR and \fBTcl_DeleteFileHandler\fR, which are Unix-specific. Most of these procedures are generic, in that they are the same for all notifiers. -However, eight of the procedures are notifier-dependent: -\fBTcl_InitNotifier\fR, \fBTcl_AlertNotifier\fR, \fBTcl_FinalizeNotifier\fR, -\fBTcl_SetTimer\fR, \fBTcl_Sleep\fR, \fBTcl_WaitForEvent\fR, -\fBTcl_CreateFileHandler\fR and \fBTcl_DeleteFileHandler\fR. To -support a new platform or to integrate Tcl with an -application-specific event loop, you must write new versions of these -procedures. +However, none of the procedures are notifier-dependent: +\fBTcl_InitNotifier\fR, \fBTcl_AlertNotifier\fR, +\fBTcl_FinalizeNotifier\fR, \fBTcl_SetTimer\fR, \fBTcl_Sleep\fR, +\fBTcl_WaitForEvent\fR, \fBTcl_CreateFileHandler\fR, +\fBTcl_DeleteFileHandler\fR and \fBTcl_ServiceModeHook\fR. To support a +new platform or to integrate Tcl with an application-specific event loop, +you must write new versions of these procedures. .PP \fBTcl_InitNotifier\fR initializes the notifier state and returns a handle to the notifier state. Tcl calls this @@ -445,7 +462,9 @@ procedure when initializing a Tcl interpreter. Similarly, called by \fBTcl_Finalize\fR when shutting down a Tcl interpreter. .PP \fBTcl_WaitForEvent\fR is the lowest-level procedure in the notifier; -it is responsible for waiting for an ``interesting'' event to occur or +it is responsible for waiting for an +.QW interesting +event to occur or for a given time to elapse. Before \fBTcl_WaitForEvent\fR is invoked, each of the event sources' setup procedure will have been invoked. The \fItimePtr\fR argument to @@ -459,13 +478,13 @@ to occur; it should not actually process the event in any way. Later on, the event sources will process the raw events and create Tcl_Events on the event queue in their \fIcheckProc\fR procedures. -However, on some platforms (such as Windows) this isn't possible; +However, on some platforms (such as Windows) this is not possible; events may be processed in \fBTcl_WaitForEvent\fR, including queuing Tcl_Events and more (for example, callbacks for native widgets may be invoked). The return value from \fBTcl_WaitForEvent\fR must be either 0, 1, or \-1. On platforms such as Windows where events get processed in \fBTcl_WaitForEvent\fR, a return value of 1 means that there may be more -events still pending that haven't been processed. This is a sign to the +events still pending that have not been processed. This is a sign to the caller that it must call \fBTcl_WaitForEvent\fR again if it wants all pending events to be processed. A 0 return value means that calling \fBTcl_WaitForEvent\fR again will not have any effect: either this is a @@ -480,7 +499,9 @@ forever because there were no active event sources and the timeout was infinite. .PP \fBTcl_AlertNotifier\fR is used in multithreaded applications to allow -any thread to "wake up" the notifier to alert it to new events on its +any thread to +.QW "wake up" +the notifier to alert it to new events on its queue. \fBTcl_AlertNotifier\fR requires as an argument the notifier handle returned by \fBTcl_InitNotifier\fR. .PP @@ -490,11 +511,18 @@ invoked by \fBTcl_SetMaxBlockTime\fR whenever the maximum blocking time has been reduced. \fBTcl_SetTimer\fR should arrange for the external event loop to invoke \fBTcl_ServiceAll\fR after the specified interval even if no events have occurred. This interface is needed -because \fBTcl_WaitForEvent\fR isn't invoked when there is an external +because \fBTcl_WaitForEvent\fR is not invoked when there is an external event loop. If the notifier will only be used from \fBTcl_DoOneEvent\fR, then \fBTcl_SetTimer\fR need not do anything. .PP +\fBTcl_ServiceModeHook\fR is called by the platform-independent portion +of the notifier when client code makes a call to +\fBTcl_SetServiceMode\fR. This hook is provided to support operating +systems that require special event handling when the application is in +a modal loop (the Windows notifier, for instance, uses this hook to +create a communication window). +.PP On Unix systems, the file event source also needs support from the notifier. The file event source consists of the \fBTcl_CreateFileHandler\fR and \fBTcl_DeleteFileHandler\fR @@ -507,7 +535,39 @@ in their respective manual pages. The easiest way to create a new notifier is to look at the code for an existing notifier, such as the files \fBunix/tclUnixNotfy.c\fR or \fBwin/tclWinNotify.c\fR in the Tcl source distribution. - +.SH "REPLACING THE NOTIFIER" +.PP +A notifier that has been written according to the conventions above +can also be installed in a running process in place of the standard +notifier. This mechanism is used so that a single executable can be +used (with the standard notifier) as a stand-alone program and reused +(with a replacement notifier in a loadable extension) as an extension +to another program, such as a Web browser plugin. +.PP +To do this, the extension makes a call to \fBTcl_SetNotifier\fR +passing a pointer to a \fBTcl_NotifierProcs\fR data structure. The +structure has the following layout: +.PP +.CS +typedef struct Tcl_NotifierProcs { + Tcl_SetTimerProc *\fIsetTimerProc\fR; + Tcl_WaitForEventProc *\fIwaitForEventProc\fR; + Tcl_CreateFileHandlerProc *\fIcreateFileHandlerProc\fR; + Tcl_DeleteFileHandlerProc *\fIdeleteFileHandlerProc\fR; + Tcl_InitNotifierProc *\fIinitNotifierProc\fR; + Tcl_FinalizeNotifierProc *\fIfinalizeNotifierProc\fR; + Tcl_AlertNotifierProc *\fIalertNotifierProc\fR; + Tcl_ServiceModeHookProc *\fIserviceModeHookProc\fR; +} \fBTcl_NotifierProcs\fR; +.CE +.PP +Following the call to \fBTcl_SetNotifier\fR, the pointers given in +the \fBTcl_NotifierProcs\fR structure replace whatever notifier had +been installed in the process. +.PP +It is extraordinarily unwise to replace a running notifier. Normally, +\fBTcl_SetNotifier\fR should be called at process initialization time +before the first call to \fBTcl_InitNotifier\fR. .SH "EXTERNAL EVENT LOOPS" .PP The notifier interfaces are designed so that Tcl can be embedded into @@ -568,9 +628,8 @@ then calls to \fBTcl_ServiceAll\fR will behave normally. mode, which should be restored when the recursive loop exits. \fBTcl_GetServiceMode\fR returns the current value of the service mode. - .SH "SEE ALSO" -\fBTcl_CreateFileHandler\fR, \fBTcl_DeleteFileHandler\fR, \fBTcl_Sleep\fR, -\fBTcl_DoOneEvent\fR, \fBThread(3)\fR +Tcl_CreateFileHandler(3), Tcl_DeleteFileHandler(3), Tcl_Sleep(3), +Tcl_DoOneEvent(3), Thread(3) .SH KEYWORDS event, notifier, event queue, event sources, file events, timer, idle, service mode, threads |