[AD] Some news from the QNX port

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

The QNX port now compiles again right out of the box. In fullscreen mode, it
works more or less but in windowed mode it segfaults.

It turns out that's a synchronization problem: the windowed driver is very,
very slow, especially in the GUI routines where they are many calls to
scare_mouse()/unscare_mouse().

The problem: scare_mouse() is called by the main thread, stops the mouse
timer that is responsible for redrawing the mouse cursor, then calls
show_mouse(NULL), which sets _mouse_screen to NULL. Now there is a race
condition in this mechanism: the 'stop mouse timer' command may be issued
after the timer thread has started redrawing the mouse cursor. So in the
middle of this retrace, _mouse_screen is set to NULL and the blit() function
issues a SIGSEGV.

The problem originates in src/timer.c: remove_int() and _handle_timer_tick()
are not synchronized at all. Sort of a soft mutex already exists (static int
timer_semaphore) but it is not used by remove_int(). If I let the function
use it (while (timer_semaphore) ;), the whole program freezes under QNX
because the main thread eats all the CPU cycles. The only solution is to use
a real mutex: with the patch attached to this message, the program no longer
segfaults nor freezes.

Hence the question: should we quickly devise the mini synchronization API we
have been talking about for months ? Only 4 calls
(create/destroy/lock/unlock) because the Win32's equivalent of
pthread_mutex_trylock() dubbed TryEnterCriticalSection() is not supported
under Win9x. We would only use it in src/timer.c and we could ultimately
keep it private for the 4.0 release.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx

Attachment: timer_sync.diff
Description: Binary data