Re: [AD] X11 unresponsiveness

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2004-07-13 at 16:07 -0700, Chris wrote:
> Elias Pschernig wrote:
> > Well, the patch works perfectly here so far. I'm only concerned about
> > possible race conditions.
> 
> As Evert said, there's no way to 100% reliably fix this.. unless we can 
> find a way to temporarilly push the process into real-time mode or 
> disable signals, check the semaphore lock (durring which a signal can't 
> happen) and finally restore it. But I fear the overhead that such a 
> technique would introduce.
> 
> > And so the responsiveness problem is solved. But I still want to apply
> > the patch first, updated version attached (thanks to SF who finally let
> > me made it).
> 
> There's a few problems with the patch I have, though. First, it 
> globalizes an _xwin_private_* function, which are designed to be static 
> (hence the _private portion). Second, it removes the XLOCK from the 
> catch-up loop (so if a signal happens when it's trying to catch up, 
> we'll have problems). And third.. it's a hack. Granted it's probably the 
> most elegant way to handle the problem.. but it's obvious the signal 
> handler and locking mechanism just aren't designed to interact this way.
> 

Did you see the change I made? I call the handler already when the lock
count is still 1, so if another signal happens at that time, it does the
right thing. With that, I think, it is safe to commit. It has no
additional race condition possibility compared to the current version,
and improves expal and the demo a lot. So, independent of the polling
idea, I think it can be applied.

-- 
Elias Pschernig