During the day, I have programs running which make literally hundreds of thousands of timestamps. There were noticeable glitches in the regular timestamps, in some cases, the stamp was delayed by 0.4 to 0.5 seconds, an enormously long time by computer standards.
I wrote a test program which is the heart of the timestamp loop and ran it for over 7 hours yesterday evening, and found that I had 76 gaps in time. One noticeable segment seemed to occur with high system activity, it had 7 or 8 gaps clustered together in about 3 or 4 seconds. Apparently this is traceable to the nanosleep() call not returning from the set interval, but at a later time, apparently held up by signal handlers. (my current impression) As the manual says, "If the call is interrupted by a signal handler, nanosleep() returns -1, sets errno to EINTR and writes the remaining time into the structure pointed to by rem unless rem in NULL. The value of *rem can then be used to call nanosleep() again and complete the specified pause." Unfortunately, nanosleep is coming back live but after a long delay, in my case, as shown by the timestamps. Do I interpret the manual to suggest that nanosleep is being suddenly terminated, and I should call it again? My initial impression is that nanosleep is being delayed, not suddenly terminated. I guess I have to put some more code in that timestamp checking program to catch the err and see what happened. It would be very nice to have an uninterruptable timer call. Randall _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
