On Mon, 23 Jun 2008 22:25:53 +0300, Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> 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.
Exactly this seems to have happened now. Wouldn't it be possible, at
least as a workaround, to call select with a timeout or did I missed
something (I don't know the ion code base, I just skimmed through some
of the related code sections)?
