Re: [AD] al_acknowledge_display_disconnected

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Wed, May 23, 2012 at 2:25 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Tue, 22 May 2012 19:09:34 -0600, Trent Gamblin <trent@xxxxxxxxxx> wrote:
>>
>> The Allegro event is sent first thing when the iOS event is received
>> by Allegro. After that, that method, which is called from some other
>> thread, waits for the display to be destroyed and then does some
>> housekeeping and returns.
>>
>
> I see.  FWIW, that's different from what I had in mind.  In my model, as
> soon as the OS event is received, the ALLEGRO_DISPLAY would be turned
> into a zombie or null display.  The housekeeping would be done and the
> method could return immediately.  It would not wait for the user to
> destroy the display first.

I think that is impossible, since the user code always can be in the
middle of, let's say, an OpenGL call. We do not have any locks around
our drawing functions (and even if we did, we allow direct use of
OpenGL). So as far as I can see, there is no way around waiting for
the user to handle the event. Only at that point do we know that they
are not accessing anything which would crash immediately when the
OpenGL context goes down.

>
> Can the current code suffer a deadlock like this?
>
> 1. OS calls handleScreenDisconnectNotification from some UI thread and
>   waits for it to return
>
> 2. handleScreenDisconnectNotification generates an
>   ALLEGRO_EVENT_DISPLAY_DISCONNECTED event and waits for the
>   user program to destroy the display
>
> 3. the user program does not see the ALLEGRO_EVENT_DISPLAY_DISCONNECTED
>   immediately, e.g. because there are other events earlier in the queue.
>   It tries to do something with the display object, e.g. set the window
>   title or resize the window.
>
> 4. (???) deadlock because the UI thread is still blocked on
>   handleScreenDisconnectNotification
>
> I don't know the iOS port so I'm just working on general principles.
> Let me know if I'm way off.

At least we can prevent them by not calling any IOS functions which
require the main thread (while we know that it is waiting on one of
those "urgent" events). Suppose the deadlock is like:

Main-Thread: waits for al_destroy_display response to the DISCONNECTED event
User-Thread: calls al_show_native_dialog (which has to call into the
main thread under IOS)

Then al_show_native_dialog would have to fail because the main thread
is blocked. It's probably unlikely enough though that we can just
ignore it :P