On 2008-06-23 19:40 +0200, Christian Glindkamp wrote:
> setitimer(ITIMER_REAL, {it_interval={0, 19}, it_value={0, 19}}, NULL) = 0
> --- SIGALRM (Alarm clock) @ 0 (0) ---
Ok, there's a small chance that it may be as I already suspected:
For some reason (bitrot maybe; I didn't actually write the code,
IIRC), the timer code sets it_interval, although it does not need
the signal repeated at static intervals. So, when this interval
is very short, Ion may never actually get far from returning
from the signal handler, until the signal is delivered again.
The attached patch might fix the issue, if this is the case.
However, now there's a potential for another race condition:
what if the signal gets delivered before we call select()?
Without repetion, we might never return from select() to
handle the timer signal. pselect() would solve this problem,
but it was not implemented in linux until 2.6.16, and glibc
has an emulation prone to the same race conditions. Also
the changes needed maybe too big for inclusion into Ion3.
(The patch is found in the Ion3+ darcs repository, however.)
--
Tuomo
Wed Jun 18 13:06:21 EEST 2008 Tuomo Valkonen <[EMAIL PROTECTED]>
* We don't really need it_interval
diff -rN -u old-ion-3-work1.1/libmainloop/signal.c
new-ion-3-work1.1/libmainloop/signal.c
--- old-ion-3-work1.1/libmainloop/signal.c 2008-06-23 22:16:51.504899340
+0300
+++ new-ion-3-work1.1/libmainloop/signal.c 2008-06-23 22:16:51.564907535
+0300
@@ -112,8 +112,8 @@
return;
}
- val.it_interval.tv_usec=val.it_value.tv_usec;
- val.it_interval.tv_sec=val.it_value.tv_sec;
+ val.it_interval.tv_usec=0;
+ val.it_interval.tv_sec=0;
if((setitimer(ITIMER_REAL, &val, NULL))){
had_tmr=TRUE;
