<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I guess you could destroy the callback with wl_callback_destroy() so<br>
it won't fire up again?</blockquote><div>Would that stop the callback from firing, considering that wl_callback_destroy() request might be received by the server _after_ an event has already been scheduled? The asynchronous nature of the protocol leaves me guessing sometimes.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 10, 2022 at 8:18 PM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Maxim<br>
<br>
On Thu, Nov 10, 2022 at 6:05 PM Maxim Kartashev<br>
<<a href="mailto:maxim.kartashev@jetbrains.com" target="_blank">maxim.kartashev@jetbrains.com</a>> wrote:<br>
><br>
> I was wondering if there's a good way of dealing with events that come from objects that are being concurrently destroyed. The scenario is as follows:<br>
> let's say a callback is created like so<br>
>  Â wl_frame_callback = wl_surface_frame(wl_surface);<br>
>  Â payload = malloc(...);<br>
>  Â wl_callback_add_listener(wl_frame_callback, &wl_frame_callback_listener, payload);<br>
> and soon after that there's<br>
>  Â wl_surface_destroy(wl_surface);<br>
>  Â free(payload);<br>
> It seems like if the frame event has already been "scheduled" to be fired at the point of wl_surface_destroy(), it might be actually delivered and the callback defined by wl_frame_callback_listener will get invoked with "payload" being free'ed already.<br>
> Is there a good way to make sure wl_frame_callback will never fire past the point of wl_surface_destroy()?<br>
<br>
I guess you could destroy the callback with wl_callback_destroy() so<br>
it won't fire up again?<br>
<br>
HTH<br>
Cheers<br>
Olivier<br>
<br>
</blockquote></div>