Marc Lehmann wrote:
A file is always readable.Since a file is trivially always readable, most event mechanisms don't go to the expense of actually generating events for files.Sometimes, yes, but you cannot depend on it.ev_io_init(&t->io.io, watch_tail_reader_cb, t->handle, EV_READ); ev_io_start(t->s->e->loop, &t->io.io); The callback is called,The solution is to simply read from the file, and not first try to use an I/O watcher.
So the io watcher shouldn't be used for files?
and in the callback, the file is read, until I reach the end of the file, at which point my attempts to read return size 0, which I understand to mean EOF.You cna verify your understanding by reading the documentation of "read" or whatever else you are using to read, indeed.
That came from the man page for "read" on MacOSX, but having had long experience with dealing with portable software, just because it says it in a man page on one OS doesn't mean it is necessarily true everywhere.
The problem is, despite the EOF point in the file having been reach, socket remains readable, and the event still fires off in a tight loop, eating up 100% CPU.How did a socket come into play? You were talking about a file earlier. Files are not sockets, so you have to decide what you are reading from. The event still fires at EOF, because you can still read from the socket (you read the eof condition).
Sorry, I am saying socket when I should be saying file descriptor.
I am trying to tail the file, so telling the event to stop watching the file for reads means that I will miss any writes a third party makes to the file.You can either poll regularly, or use an ev_stat watcher.Am I understanding this correctly, or does a file report itself as repeatedly readable when the pointer reaches the end of the file?No, it doesn't report itself so, it simply *is* readable. But keep in mind that files are always readable, and are not supported in ev_io.
Ah ok.ev_stat is suboptimal for my case (due to the delay), but it will still work.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
