From 3e86d72cac7b366add3fca5f3cd6af7635ee29cd Mon Sep 17 00:00:00 2001 From: root Date: Mon, 3 Nov 2008 15:13:53 +0000 Subject: *** empty log message *** --- ev.pod | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/ev.pod b/ev.pod index 6e7f622..20cda37 100644 --- a/ev.pod +++ b/ev.pod @@ -2000,6 +2000,24 @@ implement this functionality, due to the requirement of having a file descriptor open on the object at all times, and detecting renames, unlinks etc. is difficult. +=head3 C is a synchronous operation + +Libev doesn't normally do any kind of I/O itself, and so is not blocking +the process. The exception are C watchers - those call C, which is a synchronous operation. + +For local paths, this usually doesn't matter: unless the system is very +busy or the intervals between stat's are large, a stat call will be fast, +as the path data is suually in memory already (except when starting the +watcher). + +For networked file systems, calling C can block an indefinite +time due to network issues, and even under good conditions, a stat call +often takes multiple milliseconds. + +Therefore, it is best to avoid using C watchers on networked +paths, although this is fully supported by libev. + =head3 The special problem of stat time resolution The C system call only supports full-second resolution portably, -- cgit v1.2.3