<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 November 2013 16:40, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Wed, 20 Nov 2013 15:40:50 +0100<br>
Marek Ch <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>> wrote:<br>
<br>
> 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>
> 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>
<br>
</div>If you assume that the global_remove event has already been dispatched,<br>
then the application itself has already destroyed all the objects it<br>
needs to destroy. Or, it has scheduled their destruction, and what<br>
happens with them before that is irrelevant, because the server will<br>
ignore any requests to them anyway. Therefore I see your proposal as<br>
just redundant to something everybody needs to implement in a custom<br>
way in any case. All you would achieve is a few hundred bytes less<br>
traffic through the socket.<br>
<div class="im"><br>
> to it should be ignored (according to documentation). But that is<br>
> not true atm. Consider this piece of code:<br>
><br>
> global_remove_handler(void *data, ...)<br>
> {<br>
> int *done = data;<br>
> *done = 1;<br>
> }<br>
><br>
> ....<br>
> int done = 0;<br>
> data = &done;<br>
> ....<br>
> while (!done)<br>
> wl_display_dipatch(..);<br>
><br>
> // global_remove announcement must have been dispatched here<br>
> // so the client knows that the global is gone<br>
> // now try to make request to the removed object (wl_seat)<br>
> struct wl_proxy *p = wl_seat_get_keyboard(seat);<br>
><br>
> 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>
<br>
</div>That is not what ignoring means. It means the server will ignore the<br>
request (and "ignore" is still a slightly wrong word, since the server<br>
needs to prevent fatal protocol errors here, that may arise from the<br>
race).<br></blockquote><div> </div><div>That is what I didn't understand correctly. I thought that the request should be<br></div><div>ignored right on the client side.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, the C function syntax may add some confusion. It might look like<br>
the server is returning a new object, but that is not the case. The new<br>
object is created on the client side, and returned from the function.<br>
What happens on the wire is that the server just gets notified that<br>
there now is a new protocol object. The server cannot deny that.<br>
<br>
Returning NULL is not an option unless malloc() fails.<br></blockquote><div><br>I know the object is created on the client side. But as I wrote - any other<br></div><div>way of "ignoring" the request on client side did not strike me<br>
</div><div>(check if proxy is valid -> if not then return NULL).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><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>You are only pushing the race to a slightly different place. The race<br>
is still there when the global_remove has not yet been processed<br>
in the client, and all the inert object stuff has to be implemented in<br>
all servers. You just make the race a bit harder to hit, so I do not see<br>
any benefit.<br></blockquote><div><br>I assumed the global_remove has been processed.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> 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>
> and any further use of the proxy would check if the proxy is valid.<br>
><br>
> -> dispatch global_remove<br>
> -> wayland-defined listener: mark proxy invalid or whatever<br>
> -> user's listener: do what user needs<br>
><br>
> So as a response for an event there could be called two methods, one<br>
> 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>Sorry?<br></blockquote><div><br></div><div>It was just stupid example. Nothing better did strike me before.<br></div><div>I wouldn't define own display listener (but it would be possible,<br></div><div>so I used it as an example)<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> I know I'm a pedant but I'm just trying to validate the implementation<br>
> against<br>
> what is written in documentation.<br>
<br>
</div>Sure, we probably miss the proper global_remove handling in many<br>
places, especially in clients, but this is not the way.<br>
<br>
I'm not sure what problem you are trying to solve.<br>
<br></blockquote><div>The only thing I'm trying to solve is that the wayland implementation seems<br>behaving a little bit differently than is asserted in documentation.<br>But maybe I just misunderstood it and as you wrote:<br>
> Therefore I see your proposal as<br>
> just redundant to something everybody needs to implement in a custom<br>> way in any case. All you would achieve is a few hundred bytes less<br>
> traffic through the socket.<br></div><div>I admit the proposal wouldn't bring much.<br></div><div>Thank you for your time and patient answers :)<br></div><div><br></div><div>Thanks,<br>Marek Ch<br><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
pq<br>
<div class=""><div class="h5"><br>
> On 18 November 2013 18:49, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
><br>
> > 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>
> > ><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<br>
> > 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<br>
> > now<br>
> > > { anything user wants ... } // .............<br>
> > ><br>
> > > So, basically, the result would be triggering an action defined by<br>
> > 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>
> > 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>
> ><br>
<br>
</div></div></blockquote></div><br></div></div>