sullivan@esquire.UUCP (David J. Sullivan) (06/28/89)
I've noticed something that is quite vexing and a bit confusing:
tail -f's on files that don't change often can stop working. In
essence, the code looks like:
for (;;)
{ sleep(1);
while ((n = read (0, bin, BUFSIZ)) > 0)
(void)write (1, bin, n);
}
In fact, any sort of read on something that might not have data for
quite a while -- sometimes as little as 15 minutes, but sometimes
longer -- can go into the big sleep and not wake up.
Bopping these programs with other signals can sometimes wake them up
(bringing them to the foreground, stopping them and then backgrounding
them again, for example).
FYI, this is at OSx 4.1-880930 on a 98x in the ucb universe. I
haven't gotten 5.0 up yet, so I can't say if it's different.
Can anyone shed some light on this? Is this a bug, or what?
Thanks!
David J. Sullivan
Davis Polk & Wardwell, 14 Wall Street, NYC 10005 212/266-0730
ARPA: sullivan@acf4.nyu.edu
UUCP: {uunet|cmcl2}!esquire!sullivancsg@pyramid.pyramid.com (Carl S. Gutekunst) (07/06/89)
In article <1290@esquire.UUCP> sullivan@esquire.UUCP (David J. Sullivan) writes: >I've noticed something that is quite vexing and a bit confusing: >tail -f's on files that don't change often can stop working. Actually, it can happen even when the file *does* change. The bug is in the sleep(1); call, which occasionally doesn't wake up. (I ran the test for days on my 9840 before it happened -- but it definitely *does* happen.) This should be reported to pyramid!bugs. <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/09/89)
There were two bugs that were responsible for all the various interval-timer- related problems discussed here: one in libc.a, and one in the kernel. Fixes for both were slipped into OSx 5.0, but will be difficult to incorporate into earlier releases. No one has reported this above priority 3, so we'll let it go at that. E-mail to me if you want details. <csg>