Subversion Repositories or1k_old

'\"

'\" Copyright (c) 1995-1997 Sun Microsystems, Inc.

'\"

'\" 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.1.1.1 2002-01-16 10:25:24 markom Exp $

'\"

.so man.macros

.TH Notifier 3 8.0 Tcl "Tcl Library Procedures"

.BS

.VS

.SH NAME

Tcl_CreateEventSource, Tcl_DeleteEventSource, Tcl_SetMaxBlockTime, Tcl_QueueEvent, Tcl_DeleteEvents, Tcl_WaitForEvent, Tcl_SetTimer, Tcl_ServiceAll, Tcl_ServiceEvent, Tcl_GetServiceMode, Tcl_SetServiceMode \- the event queue and notifier interfaces

.SH SYNOPSIS

.nf

\fB#include \fR

.sp

\fBTcl_CreateEventSource\fR(\fIsetupProc, checkProc, clientData\fB)\fR

.sp

\fBTcl_DeleteEventSource\fR(\fIsetupProc, checkProc, clientData\fB)\fR

.sp

\fBTcl_SetMaxBlockTime\fR(\fItimePtr\fB)\fR

.sp

\fBTcl_QueueEvent\fR(\fIevPtr, position\fR)

.VS

.sp

\fBTcl_DeleteEvents\fR(\fIdeleteProc, clientData\fR)

.sp

int

\fBTcl_WaitForEvent\fR(\fItimePtr\fR)

.sp

\fBTcl_SetTimer\fR(\fItimePtr\fR)

.sp

int

\fBTcl_ServiceAll\fR()

.sp

int

\fBTcl_ServiceEvent\fR(\fIflags\fR)

.sp

int

\fBTcl_GetServiceMode\fR()

.sp

int

\fBTcl_SetServiceMode\fR(\fImode\fR)

.VE

.SH ARGUMENTS

.AS Tcl_EventDeleteProc milliseconds

.AS Tcl_EventSetupProc *setupProc

.AP Tcl_EventSetupProc *setupProc in

Procedure to invoke to prepare for event wait in \fBTcl_DoOneEvent\fR.

.AP Tcl_EventCheckProc *checkProc in

Procedure for \fBTcl_DoOneEvent\fR to invoke after waiting for

events.  Checks to see if any events have occurred and, if so,

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

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

is NULL, it means there is no maximum wait time:  wait forever if

necessary.

.AP Tcl_Event *evPtr in

An event to add to the event queue.  The storage for the event must

have been allocated by the caller using \fBTcl_Alloc\fR or \fBckalloc\fR.

.AP Tcl_QueuePosition position in

Where to add the new event in the queue:  \fBTCL_QUEUE_TAIL\fR,

\fBTCL_QUEUE_HEAD\fR, or \fBTCL_QUEUE_MARK\fR.

.AP int flags in

What types of events to service.  These flags are the same as those

passed to \fBTcl_DoOneEvent\fR.

.AP Tcl_EventDeleteProc *deleteProc in

Procedure to invoke for each queued event in \fBTcl_DeleteEvents\fR.

.VS

.AP int mode in

Inidicates whether events should be serviced by \fBTcl_ServiceAll\fR.

Must be one of \fBTCL_SERVICE_NONE\fR or \fBTCL_SERVICE_ALL\fR.

.VE

.BE

.SH INTRODUCTION

.PP

.VS

The interfaces described here are used to customize the Tcl event

loop.  The two most common customizations are to add new sources of

events and to merge Tcl's event loop with some other event loop, such

as one provided by an application in which Tcl is embedded.  Each of

these tasks is described in a separate section below.

.VE

.PP

The procedures in this manual entry are the building blocks out of which

the Tcl event notifier is constructed.  The event notifier is the lowest

layer in the Tcl event mechanism.  It consists of three things:

.IP [1]

Event sources: these represent the ways in which events can be

generated.  For example, there is a timer event source that implements

the \fBTcl_CreateTimerHandler\fR procedure and the \fBafter\fR

command, and there is a file event source that implements the

\fBTcl_CreateFileHandler\fR procedure on Unix systems.  An event

source must work with the notifier to detect events at the right

times, record them on the event queue, and eventually notify

higher-level software that they have occurred.  The procedures

\fBTcl_CreateEventSource\fR, \fBTcl_DeleteEventSource\fR,

and \fBTcl_SetMaxBlockTime\fR, \fBTcl_QueueEvent\fR, and

\fBTcl_DeleteEvents\fR are used primarily by event sources.

.IP [2]

The event queue: there is a single queue for the whole application,

containing events that have been detected but not yet serviced.  Event

sources place events onto the queue so that they may be processed in

order at appropriate times during the event loop. The event queue

guarantees a fair discipline of event handling, so that no event

source can starve the others.  It also allows events to be saved for

servicing at a future time.

.VS

\fBTcl_QueueEvent\fR is used (primarily

by event sources) to add events to the event queue and

\fBTcl_DeleteEvents\fR is used to remove events from the queue without

processing them.

.IP [3]

The event loop: in order to detect and process events, the application

enters a loop that waits for events to occur, places them on the event

queue, and then processes them.  Most applications will do this by

calling the procedure \fBTcl_DoOneEvent\fR, which is described in a

separate manual entry.

.PP

Most Tcl applications need not worry about any of the internals of

the Tcl notifier.  However, the notifier now has enough flexibility

to be retargeted either for a new platform or to use an external event

loop (such as the Motif event loop, when Tcl is embedded in a Motif

application).  The procedures \fBTcl_WaitForEvent\fR and

\fBTcl_SetTimer\fR are normally implemented by Tcl, but may be

replaced with new versions to retarget the notifier (the \fBTcl_Sleep\fR,

\fBTcl_CreateFileHandler\fR, and \fBTcl_DeleteFileHandler\fR must

also be replaced; see CREATING A NEW NOTIFIER below for details).

The procedures \fBTcl_ServiceAll\fR, \fBTcl_ServiceEvent\fR,

\fBTcl_GetServiceMode\fR, and \fBTcl_SetServiceMode\fR are provided

to help connect Tcl's event loop to an external event loop such as

Motif's.

.SH "NOTIFIER BASICS"

.VE

.PP

The easiest way to understand how the notifier works is to consider

what happens when \fBTcl_DoOneEvent\fR is called.

\fBTcl_DoOneEvent\fR is passed a \fIflags\fR argument that indicates

what sort of events it is OK to process and also whether or not to

block if no events are ready.  \fBTcl_DoOneEvent\fR does the following

things:

.IP [1]

Check the event queue to see if it contains any events that can

be serviced.  If so, service the first possible event, remove it

.VS

from the queue, and return.  It does this by calling

\fBTcl_ServiceEvent\fR and passing in the \fIflags\fR argument.

.VE

.IP [2]

Prepare to block for an event.  To do this, \fBTcl_DoOneEvent\fR

invokes a \fIsetup procedure\fR in each event source.

The event source will perform event-source specific initialization and

.VS

possibly call \fBTcl_SetMaxBlockTime\fR to limit how long

.VE

\fBTcl_WaitForEvent\fR will block if no new events occur.

.IP [3]

Call \fBTcl_WaitForEvent\fR.  This procedure is implemented differently

on different platforms;  it waits for an event to occur, based on the

information provided by the event sources.

It may cause the application to block if \fItimePtr\fR specifies

an interval other than 0.

\fBTcl_WaitForEvent\fR returns when something has happened,

such as a file becoming readable or the interval given by \fItimePtr\fR

expiring.  If there are no events for \fBTcl_WaitForEvent\fR to

wait for, so that it would block forever, then it returns immediately

and \fBTcl_DoOneEvent\fR returns 0.

.IP [4]

Call a \fIcheck procedure\fR in each event source.  The check

procedure determines whether any events of interest to this source

occurred.  If so, the events are added to the event queue.

.IP [5]

Check the event queue to see if it contains any events that can

be serviced.  If so, service the first possible event, remove it

from the queue, and return.

.IP [6]

See if there are idle callbacks pending. If so, invoke all of them and

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,

plus additional C procedures that are invoked by higher-level code

to arrange for event-driven callbacks.  The three procedures called

by the notifier consist of the setup and check procedures described

above, plus an additional procedure that is invoked when an event

is removed from the event queue for servicing.

.PP

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:

.CS

typedef void Tcl_EventSetupProc(

        ClientData \fIclientData\fR,

        int \fIflags\fR);

.CE

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.

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

source should return immediately without doing anything.  For

example, the file event source checks for the \fBTCL_FILE_EVENTS\fR

bit.

.PP

\fISetupProc\fR's job is to make sure that the application wakes up

when events of the desired type occur.  This is typically done in a

platform-dependent fashion.  For example, under Unix an event source

might call \fBTcl_CreateFileHandler\fR; under Windows it might

request notification with a Windows event.  For timer-driven event

sources such as timer events or any polled event, the event source

can call \fBTcl_SetMaxBlockTime\fR to force the application to wake

up after a specified time even if no events have occurred.

.VS

If no event source calls \fBTcl_SetMaxBlockTime\fR

then \fBTcl_WaitForEvent\fR will wait as long as necessary for an

event to occur; otherwise, it will only wait as long as the shortest

interval passed to \fBTcl_SetMaxBlockTime\fR by one of the event

sources.  If an event source knows that it already has events ready to

report, it can request a zero maximum block time.  For example, the

setup procedure for the X event source looks to see if there are

events already queued.  If there are, it calls

\fBTcl_SetMaxBlockTime\fR with a 0 block time so that

\fBTcl_WaitForEvent\fR does not block if there is no new data on the X

connection.

.VE

The \fItimePtr\fR argument to \fBTcl_WaitForEvent\fR points to

a structure that describes a time interval in seconds and

microseconds:

.CS

typedef struct Tcl_Time {

        long \fIsec\fR;

        long \fIusec\fR;

} Tcl_Time;

.CE

The \fIusec\fR field should be less than 1000000.

.PP

.VS

Information provided to \fBTcl_SetMaxBlockTime\fR

is only used for the next call to \fBTcl_WaitForEvent\fR; it is

discarded after \fBTcl_WaitForEvent\fR returns.

.VE

The next time an event wait is done each of the event sources'

setup procedures will be called again, and they can specify new

information for that event wait.

.PP

.VS

If the application uses an external event loop rather than

\fBTcl_DoOneEvent\fR, the event sources may need to call

\fBTcl_SetMaxBlockTime\fR at other times.  For example, if a new event

handler is registered that needs to poll for events, the event source

may call \fBTcl_SetMaxBlockTime\fR to set the block time to zero to

force the external event loop to call Tcl.  In this case,

\fBTcl_SetMaxBlockTime\fR invokes \fBTcl_SetTimer\fR with the shortest

interval seen since the last call to \fBTcl_DoOneEvent\fR or

\fBTcl_ServiceAll\fR.

.PP

In addition to the generic procedure \fBTcl_SetMaxBlockTime\fR, other

platform-specific procedures may also be available for

\fIsetupProc\fR, if there is additional information needed by

\fBTcl_WaitForEvent\fR on that platform.  For example, on Unix systems

the \fBTcl_CreateFileHandler\fR interface can be used to wait for file events.

.VE

.PP

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:

.CS

typedef void Tcl_EventCheckProc(

        ClientData \fIclientData\fR,

        int \fIflags\fR);

.CE

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

queue an event.  \fBTcl_DoOneEvent\fR calls each of the event sources

in turn, so they all have a chance to queue any events that are ready.

The check procedure does two things.  First, it must see if any events

have triggered.  Different event sources do this in different ways.

.PP

If an event source's check procedure detects an interesting event, it

must add the event to Tcl's event queue.  To do this, the event source

calls \fBTcl_QueueEvent\fR.  The \fIevPtr\fR argument is a pointer to

a dynamically allocated structure containing the event (see below for

more information on memory management issues).  Each event source can

define its own event structure with whatever information is relevant

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:

.CS

typedef struct Tcl_Event {

    Tcl_EventProc *\fIproc\fR;

    struct Tcl_Event *\fInextPtr\fR;

};

.CE

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

and should not be modified by the event source.

.PP

An event may be added to the queue at any of three positions, depending

on the \fIposition\fR argument to \fBTcl_QueueEvent\fR:

.IP \fBTCL_QUEUE_TAIL\fR 24

Add the event at the back of the queue, so that all other pending

events will be serviced first.  This is almost always the right

place for new events.

.IP \fBTCL_QUEUE_HEAD\fR 24

Add the event at the front of the queue, so that it will be serviced

before all other queued events.

.IP \fBTCL_QUEUE_MARK\fR 24

Add the event at the front of the queue, unless there are other

events at the front whose position is \fBTCL_QUEUE_MARK\fR;  if so,

add the new event just after all other \fBTCL_QUEUE_MARK\fR events.

This value of \fIposition\fR is used to insert an ordered sequence of

events at the front of the queue, such as a series of

Enter and Leave events synthesized during a grab or ungrab operation

in Tk.

.PP

.VS

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

.VE

in the first queued \fBTcl_Event\fR structure.

\fIProc\fR must match the following prototype:

.CS

typedef int Tcl_EventProc(

        Tcl_Event *\fIevPtr\fR,

        int \fIflags\fR);

.CE

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.

The second argument to \fIproc\fR is the \fIflags\fR argument for the

.VS

current call to \fBTcl_ServiceEvent\fR;  this is used by the event source

.VE

to return immediately if its events are not relevant.

.PP

It is up to \fIproc\fR to handle the event, typically by invoking

one or more Tcl commands or C-level callbacks.

Once the event source has finished handling the event it returns 1

to indicate that the event can be removed from the queue.

If for some reason the event source decides that the event cannot

be handled at this time, it may return 0 to indicate that the event

.VS

should be deferred for processing later;  in this case \fBTcl_ServiceEvent\fR

.VE

will go on to the next event in the queue and attempt to service it.

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.

Another example of deferring events happens in Tk if

\fBTk_RestrictEvents\fR has been invoked to defer certain kinds

of window events.

.PP

.VS

When \fIproc\fR returns 1, \fBTcl_ServiceEvent\fR will remove the

event from the event queue and free its storage.

Note that the storage for an event must be allocated by

the event source (using \fBTcl_Alloc\fR or the Tcl macro \fBckalloc\fR)

before calling \fBTcl_QueueEvent\fR, but it

will be freed by \fBTcl_ServiceEvent\fR, not by the event source.

.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:

.CS

typedef int Tcl_EventDeleteProc(

        Tcl_Event *\fIevPtr\fR,

        ClientData \fIclientData\fR);

.CE

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

point to the next event in the queue.

.VE

.SH "CREATING A NEW NOTIFIER"

.PP

The notifier consists of all the procedures described in this manual

entry, plus \fBTcl_DoOneEvent\fR and \fBTcl_Sleep\fR, which are

.VS

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, five of the procedures are notifier-dependent:

\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.

.PP

\fBTcl_WaitForEvent\fR is the lowest-level procedure in the notifier;

it is responsible for waiting for an ``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

\fBTcl_WaitForEvent\fR gives the maximum time to block for an event,

based on calls to \fBTcl_SetMaxBlockTime\fR made by setup procedures

and on other information (such as the \fBTCL_DONT_WAIT\fR bit in

\fIflags\fR).

.PP

Ideally, \fBTcl_WaitForEvent\fR should only wait for an event

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;

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

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

platform where \fBTcl_WaitForEvent\fR only waits without doing any event

processing, or \fBTcl_WaitForEvent\fR knows for sure that there are no

additional events to process (e.g. it returned because the time

elapsed).  Finally, a return value of \-1 means that the event loop is

no longer operational and the application should probably unwind and

terminate.  Under Windows this happens when a WM_QUIT message is received;

under Unix it happens when \fBTcl_WaitForEvent\fR would have waited

forever because there were no active event sources and the timeout was

infinite.

.PP

If the notifier will be used with an external event loop, then it must

also support the \fBTcl_SetTimer\fR interface.  \fBTcl_SetTimer\fR is

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

event loop.  If the

notifier will only be used from \fBTcl_DoOneEvent\fR, then

\fBTcl_SetTimer\fR need not do anything.

.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

procedures, which are described elsewhere.

.PP

The \fBTcl_Sleep\fR and \fBTcl_DoOneEvent\fR interfaces are described

elsewhere.

.PP

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 "EXTERNAL EVENT LOOPS"

.PP

The notifier interfaces are designed so that Tcl can be embedded into

applications that have their own private event loops.  In this case,

the application does not call \fBTcl_DoOneEvent\fR except in the case

of recursive event loops such as calls to the Tcl commands \fBupdate\fR

or \fBvwait\fR.  Most of the time is spent in the external event loop

of the application.  In this case the notifier must arrange for the

external event loop to call back into Tcl when something

happens on the various Tcl event sources.  These callbacks should

arrange for appropriate Tcl events to be placed on the Tcl event queue.

.PP

Because the external event loop is not calling \fBTcl_DoOneEvent\fR on

a regular basis, it is up to the notifier to arrange for

\fBTcl_ServiceEvent\fR to be called whenever events are pending on the

Tcl event queue.  The easiest way to do this is to invoke

\fBTcl_ServiceAll\fR at the end of each callback from the external

event loop.  This will ensure that all of the event sources are

polled, any queued events are serviced, and any pending idle handlers

are processed before returning control to the application.  In

addition, event sources that need to poll for events can call

\fBTcl_SetMaxBlockTime\fR to force the external event loop to call

Tcl even if no events are available on the system event queue.

.PP

As a side effect of processing events detected in the main external

event loop, Tcl may invoke \fBTcl_DoOneEvent\fR to start a recursive event

loop in commands like \fBvwait\fR.  \fBTcl_DoOneEvent\fR will invoke

the external event loop, which will result in callbacks as described

in the preceding paragraph, which will result in calls to

\fBTcl_ServiceAll\fR.  However, in these cases it is undesirable to

service events in \fBTcl_ServiceAll\fR.  Servicing events there is

unnecessary because control will immediately return to the

external event loop and hence to \fBTcl_DoOneEvent\fR, which can

service the events itself.  Furthermore, \fBTcl_DoOneEvent\fR is

supposed to service only a single event, whereas \fBTcl_ServiceAll\fR

normally services all pending events.  To handle this situation,

\fBTcl_DoOneEvent\fR sets a flag for \fBTcl_ServiceAll\fR

that causes it to return without servicing any events.

This flag is called the \fIservice mode\fR;

\fBTcl_DoOneEvent\fR restores it to its previous value before it returns.

.PP

In some cases, however, it may be necessary for \fBTcl_ServiceAll\fR

to service events

even when it has been invoked from \fBTcl_DoOneEvent\fR.  This happens

when there is yet another recursive event loop invoked via an

event handler called by \fBTcl_DoOneEvent\fR (such as one that is

part of a native widget).  In this case, \fBTcl_DoOneEvent\fR may not

have a chance to service events so \fBTcl_ServiceAll\fR must service

them all.  Any recursive event loop that calls an external event

loop rather than \fBTcl_DoOneEvent\fR must reset the service mode so

that all events get processed in \fBTcl_ServiceAll\fR.  This is done

by invoking the \fBTcl_SetServiceMode\fR procedure.  If

\fBTcl_SetServiceMode\fR is passed \fBTCL_SERVICE_NONE\fR, then calls

to \fBTcl_ServiceAll\fR will return immediately without processing any

events.  If \fBTcl_SetServiceMode\fR is passed \fBTCL_SERVICE_ALL\fR,

then calls to \fBTcl_ServiceAll\fR will behave normally.

\fBTcl_SetServiceMode\fR returns the previous value of the service

mode, which should be restored when the recursive loop exits.

\fBTcl_GetServiceMode\fR returns the current value of the service

mode.

.VE

.SH KEYWORDS

event, notifier, event queue, event sources, file events, timer, idle, service mode