… | |
… | |
983 | In general you can register as many read and/or write event watchers per |
983 | In general you can register as many read and/or write event watchers per |
984 | fd as you want (as long as you don't confuse yourself). Setting all file |
984 | fd as you want (as long as you don't confuse yourself). Setting all file |
985 | descriptors to non-blocking mode is also usually a good idea (but not |
985 | descriptors to non-blocking mode is also usually a good idea (but not |
986 | required if you know what you are doing). |
986 | required if you know what you are doing). |
987 | |
987 | |
988 | You have to be careful with dup'ed file descriptors, though. Some backends |
|
|
989 | (the linux epoll backend is a notable example) cannot handle dup'ed file |
|
|
990 | descriptors correctly if you register interest in two or more fds pointing |
|
|
991 | to the same underlying file/socket/etc. description (that is, they share |
|
|
992 | the same underlying "file open"). |
|
|
993 | |
|
|
994 | If you must do this, then force the use of a known-to-be-good backend |
988 | If you must do this, then force the use of a known-to-be-good backend |
995 | (at the time of this writing, this includes only C<EVBACKEND_SELECT> and |
989 | (at the time of this writing, this includes only C<EVBACKEND_SELECT> and |
996 | C<EVBACKEND_POLL>). |
990 | C<EVBACKEND_POLL>). |
997 | |
991 | |
998 | Another thing you have to watch out for is that it is quite easy to |
992 | Another thing you have to watch out for is that it is quite easy to |
… | |
… | |
1033 | |
1027 | |
1034 | =head3 The special problem of dup'ed file descriptors |
1028 | =head3 The special problem of dup'ed file descriptors |
1035 | |
1029 | |
1036 | Some backends (e.g. epoll), cannot register events for file descriptors, |
1030 | Some backends (e.g. epoll), cannot register events for file descriptors, |
1037 | but only events for the underlying file descriptions. That means when you |
1031 | but only events for the underlying file descriptions. That means when you |
1038 | have C<dup ()>'ed file descriptors and register events for them, only one |
1032 | have C<dup ()>'ed file descriptors or weirder constellations, and register |
1039 | file descriptor might actually receive events. |
1033 | events for them, only one file descriptor might actually receive events. |
1040 | |
1034 | |
1041 | There is no workaround possible except not registering events |
1035 | There is no workaround possible except not registering events |
1042 | for potentially C<dup ()>'ed file descriptors, or to resort to |
1036 | for potentially C<dup ()>'ed file descriptors, or to resort to |
1043 | C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>. |
1037 | C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>. |
1044 | |
1038 | |
… | |
… | |
1496 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1490 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1497 | to fall back to regular polling again even with inotify, but changes are |
1491 | to fall back to regular polling again even with inotify, but changes are |
1498 | usually detected immediately, and if the file exists there will be no |
1492 | usually detected immediately, and if the file exists there will be no |
1499 | polling. |
1493 | polling. |
1500 | |
1494 | |
|
|
1495 | =head3 Inotify |
|
|
1496 | |
|
|
1497 | When C<inotify (7)> support has been compiled into libev (generally only |
|
|
1498 | available on Linux) and present at runtime, it will be used to speed up |
|
|
1499 | change detection where possible. The inotify descriptor will be created lazily |
|
|
1500 | when the first C<ev_stat> watcher is being started. |
|
|
1501 | |
|
|
1502 | Inotify presense does not change the semantics of C<ev_stat> watchers |
|
|
1503 | except that changes might be detected earlier, and in some cases, to avoid |
|
|
1504 | making regular C<stat> calls. Even in the presense of inotify support |
|
|
1505 | there are many cases where libev has to resort to regular C<stat> polling. |
|
|
1506 | |
|
|
1507 | (There is no support for kqueue, as apparently it cannot be used to |
|
|
1508 | implement this functionality, due to the requirement of having a file |
|
|
1509 | descriptor open on the object at all times). |
|
|
1510 | |
1501 | =head3 The special problem of stat time resolution |
1511 | =head3 The special problem of stat time resolution |
1502 | |
1512 | |
1503 | The C<stat ()> syscall only supports full-second resolution portably, and |
1513 | The C<stat ()> syscall only supports full-second resolution portably, and |
1504 | even on systems where the resolution is higher, many filesystems still |
1514 | even on systems where the resolution is higher, many filesystems still |
1505 | only support whole seconds. |
1515 | only support whole seconds. |
… | |
… | |
1559 | =item const char *path [read-only] |
1569 | =item const char *path [read-only] |
1560 | |
1570 | |
1561 | The filesystem path that is being watched. |
1571 | The filesystem path that is being watched. |
1562 | |
1572 | |
1563 | =back |
1573 | =back |
|
|
1574 | |
|
|
1575 | =head3 Examples |
1564 | |
1576 | |
1565 | Example: Watch C</etc/passwd> for attribute changes. |
1577 | Example: Watch C</etc/passwd> for attribute changes. |
1566 | |
1578 | |
1567 | static void |
1579 | static void |
1568 | passwd_cb (struct ev_loop *loop, ev_stat *w, int revents) |
1580 | passwd_cb (struct ev_loop *loop, ev_stat *w, int revents) |