1fileevent(3)          User Contributed Perl Documentation         fileevent(3)
2
3
4

NAME

6       Tk::fileevent - Execute a callback when a filehandle becomes readable
7       or writable
8

SYNOPSIS

10       $widget->fileevent(fileHandle,readable?,callback?)
11
12       $widget->fileevent(fileHandle,writable?,callback?)
13

DESCRIPTION

15       This command is used to create file event handlers.  A file event
16       handler is a binding between a filehandle and a callback, such that the
17       callback is evaluated whenever the filehandle becomes readable or
18       writable.  File event handlers are most commonly used to allow data to
19       be received from another process on an event-driven basis, so that the
20       receiver can continue to interact with the user while waiting for the
21       data to arrive.  If an application invokes "<>", "sysread" or "read" on
22       a blocking filehandle when there is no input data available, the
23       process will block; until the input data arrives, it will not be able
24       to service other events, so it will appear to the user to ``freeze
25       up''.  With fileevent, the process can tell when data is present and
26       only invoke gets or read when they won't block.
27
28       The fileHandle argument to fileevent refers to an open filehandle, such
29       as the return value from a previous open or socket command.  If the
30       callback argument is specified, then fileevent creates a new event
31       handler:  callback will be evaluated whenever the filehandle becomes
32       readable or writable (depending on the argument to fileevent).  In this
33       case fileevent returns an empty string.  The readable and writable
34       event handlers for a file are independent, and may be created and
35       deleted separately.  However, there may be at most one readable and one
36       writable handler for a file at a given time in a given interpreter.  If
37       fileevent is called when the specified handler already exists in the
38       invoking interpreter, the new callback replaces the old one.
39
40       If the callback argument is not specified, fileevent returns the
41       current callback for fileHandle, or an empty string if there is none.
42       If the callback argument is specified as an empty string then the event
43       handler is deleted, so that no callback will be invoked.  A file event
44       handler is also deleted automatically whenever its filehandle is closed
45       or its interpreter is deleted.
46
47       A filehandle is considered to be readable if there is unread data
48       available on the underlying device.  A filehandle is also considered to
49       be readable if an end of file or error condition is present on the
50       underlying file or device.  It is important for callback to check for
51       these conditions and handle them appropriately;  for example, if there
52       is no special check for end of file, an infinite loop may occur where
53       callback reads no data, returns, and is immediately invoked again.
54
55       A filehandle is considered to be writable if at least one byte of data
56       can be written to the underlying file or device without blocking, or if
57       an error condition is present on the underlying file or device.
58
59       Event-driven I/O works best for filehandles that have been placed into
60       nonblocking mode.  In blocking mode, a "print" command may block if you
61       give it more data than the underlying file or device can accept, and a
62       "<>", "sysread" or "read" command will block if you attempt to read
63       more data than is ready;  no events will be processed while the
64       commands block.  In nonblocking mode "print", "<>", "sysread" and
65       "read" never block.  See the documentation for the individual commands
66       for information on how they handle blocking and nonblocking
67       filehandles.
68
69       The callback for a file event is executed in the context of $widget
70       with which fileevent was invoked.  If an error occurs while executing
71       the callback then the Tk::Error mechanism is used to report the error.
72       In addition, the file event handler is deleted if it ever returns an
73       error;  this is done in order to prevent infinite loops due to buggy
74       handlers.
75

BUGS

77       On windows platforms fileevent is limited in the types of filehandles
78       that behave correctly. Making filehandles non-blocking is only
79       implemented on a subset of UNIX platforms (see Tk::IO).
80

CREDITS

82       fileevent is based on the addinput command created by Mark Diekhans.
83

SEE ALSO

85       Tk::IO Tk::callbacks
86

KEYWORDS

88       asynchronous I/O, blocking, filehandle, event handler, nonblocking,
89       readable, callback, writable.
90
91
92
93perl v5.38.0                      2023-07-21                      fileevent(3)
Impressum