Lines Matching refs:file

13    // a single header file is required
96 file descriptor being readable or a timeout occurring), and it will manage
112 for file descriptor events (C<ev_io>), the Linux C<inotify> interface
119 C<ev_check> watchers) as well as file watchers (C<ev_stat>) and even
237 also recommended for this platform, meaning it will work for most file
431 testing, this flag can be useful to conserve inotify file descriptors, as
471 parallelism (most of the file descriptors should be busy). If you are
505 dropping file descriptors, requiring a system call per change per file
511 set, which can take considerable time (one syscall per file descriptor)
516 totally I<different> file descriptors (even already closed ones, so
524 not least, it also refuses to work with some file descriptors which work
533 incident (because the same I<file descriptor> could point to a different
534 I<file description> now), so its best to avoid that. Also, C<dup ()>'ed
535 file descriptors might not work very well if you register events for both
536 file descriptors.
539 watchers for a file descriptor until it has been closed, if possible,
547 faster than epoll for maybe up to a hundred file descriptors, depending on
606 file descriptor per loop iteration. For small and medium numbers of file
1050 have no effect on the set of file descriptors being watched, or the time
1125 time the event loop detects that the file descriptor given is readable
1156 The file descriptor in the C<ev_io> watcher has become readable and/or
1226 ran out of memory, a file descriptor was found to be closed or any other
1579 =head2 C<ev_io> - is this file descriptor readable or writable?
1581 I/O watchers check whether a file descriptor is readable or writable
1590 fd as you want (as long as you don't confuse yourself). Setting all file
1604 re-test whether a file descriptor is really ready with a known-to-be good
1612 =head3 The special problem of disappearing file descriptors
1614 Some backends (e.g. kqueue, epoll) need to be told about closing a file
1616 such as C<dup2>). The reason is that you register interest in some file
1618 this interest. If another file descriptor with the same number then is
1620 fact, a different file descriptor.
1624 will assume that this is potentially a new file descriptor, otherwise
1625 it is assumed that the file descriptor stays the same. That means that
1627 descriptor even if the file descriptor number itself did not change.
1633 =head3 The special problem of dup'ed file descriptors
1635 Some backends (e.g. epoll), cannot register events for file descriptors,
1636 but only events for the underlying file descriptions. That means when you
1637 have C<dup ()>'ed file descriptors or weirder constellations, and register
1638 events for them, only one file descriptor might actually receive events.
1641 for potentially C<dup ()>'ed file descriptors, or to resort to
1646 Many people try to use C<select> (or libev) on file descriptors
1668 F</dev/urandom>), and even though the file might better be served with
1672 So avoid file descriptors pointing to files when you know it (e.g. use
1674 when you rarely read from a file instead of from a socket, and want to
1704 For example, larger servers often run out of file descriptors (because
1727 If your program is single-threaded, then you could also keep a dummy file
1745 Configures an C<ev_io> watcher. The C<fd> is the file descriptor to
1751 The file descriptor being watched.
2617 =head2 C<ev_stat> - did the file attributes just change?
2619 This watches a file system path for attribute changes. That is, it calls
2622 if it did. Starting the watcher C<stat>'s the file, so only changes that
2657 compilation environment, which means that on systems with large file
2660 use 64 bit file offsets the programs will fail. In that case you have to
2663 most noticeably displayed with ev_stat and large file support.
2666 file interfaces available by default (as e.g. FreeBSD does) and not
2667 optional. Libev cannot simply switch on large file support because it has
2688 implement this functionality, due to the requirement of having a file
2703 For networked file systems, calling C<stat ()> can block an indefinite
2713 and even on systems where the resolution is higher, most file systems
2720 stat data does change in other ways (e.g. file size).
2732 update file times then there will be a small window where the kernel uses
2733 the previous second to update file times but libev might already execute
2764 The most-recently detected attributes of the file. Although the type is
2768 some error while C<stat>ing the file.
2772 The previous attributes of the file. The callback gets invoked whenever
2783 The file system path that is being watched.
2934 This is done by examining in each prepare call which file descriptors
3559 Feed an event on the given fd, as if a file descriptor backend detected
3917 can even use F<ev.h> as header file name directly.
3951 to use the libev header file and library.
4229 of the libev API and adds file handle abstractions, asynchronous DNS and
4369 single C source file only to provide the function implementations. To use
4398 to compile this single file.
4406 in the file including F<ev.c>, and:
4424 For this of course you need the m4 file:
4536 on exotic systems. This usually limits the range of file descriptors to
4544 select/socket/connect etc. don't understand file descriptors but
4554 file descriptors to socket handles. When not defining this symbol (the
4556 correct. In some cases, programs use their own file descriptor management,
4561 If C<EV_SELECT_IS_WINSOCKET> then libev maps handles to file descriptors
4570 file descriptors again. Note that the replacement function has to close
4652 The name of the F<ev.h> header file used to include it. The default if
4654 used to virtually rename the F<ev.h> header file in case of conflicts.
4659 F<ev.c>'s idea of where to find the F<config.h> file, similarly to
4804 when you embed libev, only want to use libev functions in a single file,
4807 To use this, define C<EV_API_STATIC> and include F<ev.c> in the file that
4904 definition and a statement, respectively. See the F<ev.h> header file for
4929 This would create a file F<wrap.h> which essentially looks like this:
4942 interface) and F<EV.xs> (implementation) files. Only the F<EV.xs> file
4944 file.
4946 The usage in rxvt-unicode is simpler. It has a F<ev_cpp.h> header file
4960 And a F<ev_cpp.C> implementation file that contains libev proper and is compiled:
5107 GNU/Linux is the only common platform that supports 64 bit file/large file
5114 by enabling the large file API, which makes them incompatible with the
5117 Likewise, libev cannot enable the large file API itself as this would
5150 one up as well: On OS/X, C<select> actively limits the number of file
5231 section for details) and use the following F<evwrap.h> header file instead
5239 And compile the following F<evwrap.c> file into your project (make sure
5248 requires socket I<handles> and not socket I<file descriptors> (it is
5250 requires a mapping from file descriptors to socket handles (the Microsoft
5264 =head3 Limited number of file descriptors
5279 Another limit is the number of file descriptors in the Microsoft runtime
5399 =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)
5432 At the moment, the C<ev.h> header file provides compatibility definitions
5518 for reading on a file descriptor, time having passed or simply not having