Re: NSFileHandle notifications
Re: NSFileHandle notifications
- Subject: Re: NSFileHandle notifications
- From: Andreas Monitzer <email@hidden>
- Date: Tue, 31 Jul 2001 21:23:19 +0200
On Tuesday, July 31, 2001, at 08:11 , Chris Kane wrote:
On Monday, July 30, 2001, at 03:47 PM, Andreas Monitzer wrote:
[...]
However, when this code is run the notifications are constantly sent
("Notification without data!") and the CPU utilization is at about 25%
even when nothing happens. "waitForData" doesn't sound like it should
send notifications when no data is available. Can anyone
confirm/deny/explain this?
I think I'll implement it myself by using select().
Why not have the file handle do the reading for you with
-readInBackgroundAndNotify? I'm not sure
waitForDataInBackgroundAndNotify (which uses select()) works well (gives
the semantics you're expecting) on real files (as opposed to pipes or
sockets).
The no-data could be because there is an error occurring (say, in the
background wait) or because no data has been added to the file (your fd
is still "at EOF") but select() is returning the file descriptor as
readable anyway.
It's the "select() returns readable"-problem (I reproduced this problem
with my own implementation of waitForDataInBackgroundAndNotify).
In any case, I'd try converting to -readInBackgroundAndNotify.
I tried all three notification methods, but all continuously sent
notifications.
Charles Bennett <email@hidden> wrote:
In a former life I reported an apparent bug in select() all the way back
to NeXTSTEP 2.0
At the time it seemed that select always returned "ready" but had zero
bytes
to be read. I seem to remember thinking that it was triggered by select
calls against tty/pty file handles.
select() acts like you described, ready with 0 bytes to read. Seems to be
this very old bug. tail -f does work correctly, I think I'll have a look
at the source. Of course, I could use NSTask on tail, but that's something
I'd like to avoid.
I'll check out how FreeBSD's select() acts.
btw select() on pipes does work as expected.
andy
--
Discussion forthcoming.