jthread and handleIO(true)
Parmelan, Edouard
EP510777 at exchange.FRANCE.NCR.com
Thu Nov 19 10:21:37 PST 1998
Godmar,
> > The general case is:
> > . A thread waits for a small time.
> > . All other threads are SUSPENDED (maybe I/O or ALARM)
> > . SIGALRM is received while reschedule() loop and marked as pending.
> > . reschedule() call handleIO(true) and wait for an I/O event or
> > an alarm event before process pending signals.
> >
> > I think you should check sigPending in reschedule() before called
> > handleIO(true) as:
> >
> > if (sigPending)
> > processSignals()
> > else {
> > if (DBGEXPR(DETECTDEADLOCK...
> > handleIO(true);
> > }
> >
>
> This wouldn't fix it, would it?
It does.
> You're still have the possible race condition because your test of
> sigPending and the call to handleIO(and then select) are not atomic.
Sure but the window is small.
> It appears that blocking signals before we go into the select is the
> only way to really fix that.
No, if so, you can't receive SIGALRM.
> That shouldn't hurt us much, though,
> since it'll only happen when the system is about to go idle in select.
No, the AWT-event thread receive events from the X server by
waiting and ask if an event is in the Xlib queue.
In my case, the AWT application is locked because it's only
wait for an X event. No other thread is waiting an ALARM nor
an I/O event.
Edouard.
More information about the kaffe
mailing list