minfrin at sharp.fm
Sat Dec 6 14:34:36 CET 2008
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.
>> 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,
> Sometimes, yes, but you cannot depend on it.
> 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
> 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_stat is suboptimal for my case (due to the delay), but it will still
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
More information about the libev