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