<div dir="ltr">Oh damn, I was looking for an API to cancel a callback and couldn't find anything; didn't realize all I needed to do is destroy it. That makes it so much simpler. I'll send out a follow-up patch.<div><br></div><div>Thanks!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 24, 2016 at 4:05 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dima,<br>
<span class=""><br>
On 24 November 2016 at 06:07, Dima Ryazanov <<a href="mailto:dima@gmail.com">dima@gmail.com</a>> wrote:<br>
> When a window is being closed, the frame_done callback often runs after<br>
> the output is already destroyed, i.e:<br>
><br>
>   wayland_output_start_repaint_<wbr>loop<br>
>   input_handle_button<br>
>     wayland_output_destroy<br>
>   frame_done<br>
><br>
> To fix this, destroy the output from an idle handler (same as compositor-x11),<br>
> and also stop creating new frame_done callbacks.<br>
<br>
</span>Hm. The reason for moving destroy to an idle handler in X11, is that<br>
handle_event may be called 'in the middle of repaint'. I suspect - and<br>
Derek, please correct me if I'm wrong - that this was because we may<br>
start the X11 repaint loop, send a request, await a reply, and whilst<br>
waiting for that reply, receive a DELETE_WINDOW event which causes us<br>
to delete. Which would be bad.<br>
<br>
If that's right, then it's a different root cause. We'll never<br>
dispatch any Wayland events during repaint; we don't do so ourselves,<br>
and the only thing that could cause to is EGL, which must only be<br>
dispatching on its own separate event queue.<br>
<br>
So, if the root cause is the frame callback arriving after destroy:<br>
why not just destroy the frame callback, so we never receive it, and<br>
can destroy immediately?<br>
<br>
Cheers,<br>
Daniel<br>
</blockquote></div><br></div>