Hi all
I've been looking at /dev/rtc in order to get a process waken up at
millisec intervals nicely, which apparently works OK. My questions are:
a) portability: Apparently the linuces have /dev/rtc support across
(most?) supported platforms, but does anyone know of similar/identical
facilities in other unices ?
b) alternatives: (assuming the answer to above question is that
portability is limited) Does anyone have ideas to how a process is waken
up at regular intervals faster than is possible with select or signals
(seems to be HZ/2, HZ = 100. I know kernel may be recompiled with a
higher HZ setting, but it would be nice not having to do this).
c) reliability/scheduling (this is really a kernel hacking Q): When
programming /dev/rtc to 1024 interrupts/sec and marking the process as a
real time one (forces scheduling before anything with "normal"
priorities, call to set_scheduler or something, dont have the source in
front of me), the process will reliably wake up said number of times a
second (as seen by quering the Pentium counters). This at least until
the system gets loaded with something of similar or higher (realtime)
priority, which on my system seems to occur 1) when touching anything in
X, and 2) at rare, but regular intervals (file flushing daemon or
something). In this case my process gets waken up at 100 Hz, or HZ,
rather than 1024 Hz. I assume what happens is, that everytime the
scheduler preemts, my process gets scheduled once, does its things,
yields and will not get schedule before next preemption, because other
processes scheduled after my process yields, does not yield. So the
question after a long story is: Does anybody know of a nice way,
_without_kernel_hacking_ to get a pending high (realtime) priority task
scheduled _immediately_ and not just at the next regular timer int
preemption (this probably implies a fair amount of trickery from the
code getting the interrupt, in this case the /dev/rtc driver). The
kernel hacking point is that if willing to use a modified kernel, I
believe the Real Time Linux people have a solution at hand.
Thanks in advance,
Niels Hald Pedersen,
[EMAIL PROTECTED]
ps: I dont think linux-c-prog should be afraid of having language
philosophy/style threads like the string/pointer one recently (as long
as they are somewhat focused on C/C++ matters). I think a lot of good
points and possible misunderstandings surface.
Neither should we be afraid of words like RTFM or FMH, which are not a
priori derogative, but, admitted, expands somewhat spicy. Like UTSL and
IMHO, these are phrases having attained a specific and often useful
meaning (IMHO).
What we _should_ be afraid of is flaming and demonizing of posters,
whose views we (whoever that may be in this context) dont agree with,
find silly. Posters have vastly different backgrounds; for a great deal
of us, English is not our first language either.
-twm2c, nhp
