Re: [AD] X11 unresponsiveness

[Chris <kcat@xxxxxxxxxx>]

Elias Pschernig wrote:
> Hm, it just is an internal symbol, which is needed in different source
> files.

And once you make it non-static, it adds another global function, which 
would break ABI compatibility for 4.0.x (are we still supporting 4.0? 
and maybe .so's don't have the same export table limitations as DLLs. I 
dunno.). I wouldn't be too adverse if the _private portion was removed 
from the name, but then that would make the name the same as the current 
global. There's two things I'd do if you really wanted to go through 
with this. One, you could just create another function (say, 
_xwin_handle_input_nolock) that calls _xwin_private_handle_input.. or, 
make _xwin_handle_input take a nolock parameter that, when set to true, 
just calls _xwin_private_handle_input without locking or checking locks 
then returns, and when it's false, it just does what it does now. So the 
function would look like this:

void _xwin_handle_input(int nolock)
{
#ifndef ALLEGRO_MULTITHREADED
   if(nolock) {
      if (_xwin_input_handler)
         _xwin_input_handler();
      else
         _xwin_private_handle_input();
      return;
   }

   if (_xwin.lock_count) {
      ++_xwin_missed_input;
      return;
   }
#endif

   XLOCK();

   if (_xwin_input_handler)
      _xwin_input_handler();
   else
      _xwin_private_handle_input();

   XUNLOCK();
}

The call in xsystem.c would pass FALSE, and the call in XUNLOCK would 
pass TRUE.

> Doesn't seem like a hack at all.

What I'm saying is like a hack is changing the global _xwin_handle_input 
and its static _xwin_private_handle_input pairing (which is mirrored 
with the other _xwin* functions) just because the signal-based function 
calling and X can't get along.. for which we already have a solution 
(polling).

> Definitely better than
> the previous way of just dropping input.

Actually, input isn't dropped. It just stays in X's queue until the 
signal input handler can finally read it (at which point it seems to 
only read 5 events at a time.. which 5 really is fine otherwise).

> I agree, we should additionally encourage polling for the signals
> version.

And I think the best way to encourage it is to not bandage up the 
relatively small issue (laggy input) of a bigger problem (calling X 
routines in a timer/signal). I personally think the signal input handler 
should be dropped completely for a pure polling-based method.. however, 
I also realize that too many current programs didn't head the warning 
that some platforms may *require* polling. Though until one such 
platform comes along, I don't think anyone will take the warning seriously.

- Kitty Cat