1fileevent(n)                 Tcl Built-In Commands                fileevent(n)
2
3
4
5______________________________________________________________________________
6

NAME

8       fileevent  -  Execute  a  script  when  a  channel  becomes readable or
9       writable
10

SYNOPSIS

12       fileevent channelId readable ?script?
13
14       fileevent channelId writable ?script?
15_________________________________________________________________
16
17

DESCRIPTION

19       This command is used to create file event handlers.  A file event  han‐
20       dler  is a binding between a channel and a script, such that the script
21       is evaluated whenever the channel becomes readable or  writable.   File
22       event handlers are most commonly used to allow data to be received from
23       another process on an event-driven basis, so that the receiver can con‐
24       tinue  to  interact with the user while waiting for the data to arrive.
25       If an application invokes gets or read on a blocking channel when there
26       is  no  input  data  available, the process will block; until the input
27       data arrives, it will not be able to service other events, so  it  will
28       appear  to  the user to ``freeze up''.  With fileevent, the process can
29       tell when data is present and only invoke gets or read when they  won't
30       block.
31
32       The channelId argument to fileevent refers to an open channel such as a │
33       Tcl standard channel (stdin, stdout, or stderr), the return value  from │
34       an  invocation  of  open or socket, or the result of a channel creation │
35       command provided by a Tcl extension.
36
37       If the script argument is specified, then fileevent creates a new event
38       handler:   script  will be evaluated whenever the channel becomes read‐
39       able or writable (depending on the second argument to  fileevent).   In
40       this case fileevent returns an empty string.  The readable and writable
41       event handlers for a file are  independent,  and  may  be  created  and
42       deleted separately.  However, there may be at most one readable and one
43       writable handler for a file at a given time in a given interpreter.  If
44       fileevent  is  called  when the specified handler already exists in the
45       invoking interpreter, the new script replaces the old one.
46
47       If the script argument is not specified, fileevent returns the  current
48       script  for  channelId,  or  an  empty string if there is none.  If the
49       script argument is specified as an empty string then the event  handler
50       is deleted, so that no script will be invoked.  A file event handler is
51       also deleted automatically whenever its channel is closed or its inter‐
52       preter is deleted.
53
54       A  channel  is considered to be readable if there is unread data avail‐
55       able on the underlying device.  A channel  is  also  considered  to  be
56       readable if there is unread data in an input buffer, except in the spe‐
57       cial case where the most recent attempt to read from the channel was  a
58       gets  call  that  could  not  find a complete line in the input buffer.
59       This feature allows a file to be read a line at a time  in  nonblocking
60       mode  using  events.  A channel is also considered to be readable if an
61       end of file or error condition is present on  the  underlying  file  or
62       device.   It  is important for script to check for these conditions and
63       handle them appropriately;  for example, if there is no  special  check
64       for end of file, an infinite loop may occur where script reads no data,
65       returns, and is immediately invoked again.
66
67       A channel is considered to be writable if at least one byte of data can
68       be  written to the underlying file or device without blocking, or if an
69       error condition is present on the underlying file or device.
70
71       Event-driven I/O works best for channels that  have  been  placed  into
72       nonblocking mode with the fconfigure command.  In blocking mode, a puts
73       command may block if you give it more data than the underlying file  or
74       device can accept, and a gets or read command will block if you attempt
75       to read more data than is ready;  no events will be processed while the
76       commands  block.  In nonblocking mode puts, read, and gets never block.
77       See the documentation for the individual commands  for  information  on
78       how they handle blocking and nonblocking channels.
79
80       The  script  for  a file event is executed at global level (outside the
81       context of any Tcl procedure) in the interpreter in which the fileevent
82       command  was  invoked.   If  an error occurs while executing the script
83       then the bgerror mechanism is used to report the error.   In  addition,
84       the file event handler is deleted if it ever returns an error;  this is
85       done in order to prevent infinite loops due to buggy handlers.
86

EXAMPLE

88       In this setup GetData will be called with the channel  as  an  argument
89       whenever $chan becomes readable.
90              proc GetData {chan} {
91                  if {![eof $chan]} {
92                      puts [gets $chan]
93                  }
94              }
95
96              fileevent $chan readable [list GetData $chan]
97
98

CREDITS

100       fileevent is based on the addinput command created by Mark Diekhans.
101
102

SEE ALSO

104       bgerror(n), fconfigure(n), gets(n), puts(n), read(n), Tcl_StandardChan‐
105       nels(3)
106
107

KEYWORDS

109       asynchronous I/O, blocking, channel, event handler, nonblocking,  read‐
110       able, script, writable.
111
112
113
114Tcl                                   7.5                         fileevent(n)
Impressum