<div dir="ltr"><div><div><div><div><div><div>That is true, the race is there and I keep it in mind. But I'm talking<br>about the case, when the global_remove event has been already <br></div>dispatched (so the client should know that the global 'should' be<br>
gone). In this case the object should remain valid but all requests<br>to it should be ignored (according to documentation). But that is<br>not true atm. Consider this piece of code:<br></div></div><br></div>global_remove_handler(void *data, ...)<br>
{<br></div> int *done = data;<br></div> *done = 1;<br><div><div>}<br><br>....<br></div><div>int done = 0;<br></div><div>data = &done;<br>....<br></div><div>while (!done)<br></div><div> wl_display_dipatch(..);<br>
<br></div><div>// global_remove announcement must have been dispatched here<br></div><div>// so the client knows that the global is gone<br></div><div>// now try to make request to the removed object (wl_seat)<br></div><div>
struct wl_proxy *p = wl_seat_get_keyboard(seat);<br><br></div><div>According to the documentation the return value of<br>wl_seat_get_keyboard should be NULL (or the request should be<br>ignored some other way, but what other way?).<br>
And here is no race at all. The event is gone from<br>client's buffer and what is the state of the display doesn't matter<br>because client knows that the object is gone and should ignore it<br>further. Or am I wrong?<br>
<br></div><div>The problem is how to make the client ignore it. How to turn<br>the 'should' into 'have to'. And that is why I proposed the new<br>set of listeners that would be called right before the user's listener<br>
and could possibly change something in client's display. In the case<br>of global deletion it could just, for example, mark the proxy as invalid<br></div><div>and any further use of the proxy would check if the proxy is valid.<br>
</div><div><br></div><div>-> dispatch global_remove<br></div><div> -> wayland-defined listener: mark proxy invalid or whatever<br></div><div> -> user's listener: do what user needs<br></div><div><br></div>
<div>So as a response for an event there could be called two methods, one<br></div><div>defined by wayland for internal stuff and one defined by user.<br>It could be used for other things too. For example if display events<br>
would be handled by wayland listener then the user could define its<br>own listener for display events and could catch an error and write out<br>nice error message on his side (that's just an example!)<br><br></div><div>
I know I'm a pedant but I'm just trying to validate the implementation against<br></div><div>what is written in documentation.<br><br></div><div>Regards<br>Marek Ch<br></div></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 18 November 2013 18:49, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, 18 Nov 2013 16:54:03 +0100<br>
Marek Ch <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> in reaction to<br>
> <a href="http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html</a><br>
> I have got an idea and I like to share it with you and possibly get a<br>
> feedback.<br>
><br>
> What I was thinking about is:<br>
> Add into wl_object another variable for listener (implementation) that<br>
> would be set<br>
> when proxy is created (or set to NULL when not needed). In this new<br>
> listener would be actions that should be done in display (client's display)<br>
> before actual dispatching the event. Example with the global deletion:<br>
><br>
> client recieves global_delete event and in dispatching phase there would<br>
> these steps:<br>
> preaction_global_delete(..) // this is new<br>
> { mark proxy id as invalid or whatever } // ..............<br>
> user_global_delete(..) // this is what is now<br>
> { anything user wants ... } // .............<br>
><br>
> So, basically, the result would be triggering an action defined by display<br>
> (but on client side) on particular event coming.<br>
><br>
> Is it any way useful (I can imagine it work for example for the global<br>
> deletion) or is it just silly idea?<br>
<br>
</div></div>Hi Marek,<br>
<br>
I'm not sure I understand what you propose here, but whatever you<br>
do client-side will not remove the race, and the race is what<br>
requires compositors to turn objects inert instead of just destroying<br>
their protocol bookkeeping.<br>
<br>
The compositor may delete a global, and send the deletion events,<br>
but the events could be sitting in the compositor's send buffer,<br>
socket's buffers, or the client's receive buffer while the client<br>
is happily sending new requests on the deleted objects and not even<br>
looking at the incoming events.<br>
<br>
In fact, the client could be sending the requests even before the<br>
compositor decides to the delete global object, and the requests<br>
could already be sitting in any of the message buffers while<br>
compositor decides the global is now gone.<br>
<br>
We do need the wl_resource objects alive (but inert) in the server<br>
until the client is guaranteed to know that the protocol object is<br>
no more. Destroy request is the standard signal for that.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>