On 20 November 2013 16:40, Pekka Paalanen <[email protected]> wrote:
> On Wed, 20 Nov 2013 15:40:50 +0100 > Marek Ch <[email protected]> wrote: > > > That is true, the race is there and I keep it in mind. But I'm talking > > about the case, when the global_remove event has been already > > dispatched (so the client should know that the global 'should' be > > gone). In this case the object should remain valid but all requests > > If you assume that the global_remove event has already been dispatched, > then the application itself has already destroyed all the objects it > needs to destroy. Or, it has scheduled their destruction, and what > happens with them before that is irrelevant, because the server will > ignore any requests to them anyway. Therefore I see your proposal as > just redundant to something everybody needs to implement in a custom > way in any case. All you would achieve is a few hundred bytes less > traffic through the socket. > > > to it should be ignored (according to documentation). But that is > > not true atm. Consider this piece of code: > > > > global_remove_handler(void *data, ...) > > { > > int *done = data; > > *done = 1; > > } > > > > .... > > int done = 0; > > data = &done; > > .... > > while (!done) > > wl_display_dipatch(..); > > > > // global_remove announcement must have been dispatched here > > // so the client knows that the global is gone > > // now try to make request to the removed object (wl_seat) > > struct wl_proxy *p = wl_seat_get_keyboard(seat); > > > > According to the documentation the return value of > > wl_seat_get_keyboard should be NULL (or the request should be > > ignored some other way, but what other way?). > > That is not what ignoring means. It means the server will ignore the > request (and "ignore" is still a slightly wrong word, since the server > needs to prevent fatal protocol errors here, that may arise from the > race). > That is what I didn't understand correctly. I thought that the request should be ignored right on the client side. Also, the C function syntax may add some confusion. It might look like > the server is returning a new object, but that is not the case. The new > object is created on the client side, and returned from the function. > What happens on the wire is that the server just gets notified that > there now is a new protocol object. The server cannot deny that. > > Returning NULL is not an option unless malloc() fails. > I know the object is created on the client side. But as I wrote - any other way of "ignoring" the request on client side did not strike me (check if proxy is valid -> if not then return NULL). > > And here is no race at all. The event is gone from > > client's buffer and what is the state of the display doesn't matter > > because client knows that the object is gone and should ignore it > > further. Or am I wrong? > > You are only pushing the race to a slightly different place. The race > is still there when the global_remove has not yet been processed > in the client, and all the inert object stuff has to be implemented in > all servers. You just make the race a bit harder to hit, so I do not see > any benefit. > I assumed the global_remove has been processed. > > The problem is how to make the client ignore it. How to turn > > the 'should' into 'have to'. And that is why I proposed the new > > set of listeners that would be called right before the user's listener > > and could possibly change something in client's display. In the case > > of global deletion it could just, for example, mark the proxy as invalid > > and any further use of the proxy would check if the proxy is valid. > > > > -> dispatch global_remove > > -> wayland-defined listener: mark proxy invalid or whatever > > -> user's listener: do what user needs > > > > So as a response for an event there could be called two methods, one > > defined by wayland for internal stuff and one defined by user. > > It could be used for other things too. For example if display events > > would be handled by wayland listener then the user could define its > > own listener for display events and could catch an error and write out > > nice error message on his side (that's just an example!) > > Sorry? > It was just stupid example. Nothing better did strike me before. I wouldn't define own display listener (but it would be possible, so I used it as an example) > > I know I'm a pedant but I'm just trying to validate the implementation > > against > > what is written in documentation. > > Sure, we probably miss the proper global_remove handling in many > places, especially in clients, but this is not the way. > > I'm not sure what problem you are trying to solve. > > The only thing I'm trying to solve is that the wayland implementation seems behaving a little bit differently than is asserted in documentation. But maybe I just misunderstood it and as you wrote: > Therefore I see your proposal as > just redundant to something everybody needs to implement in a custom > way in any case. All you would achieve is a few hundred bytes less > traffic through the socket. I admit the proposal wouldn't bring much. Thank you for your time and patient answers :) Thanks, Marek Ch > Thanks, > pq > > > On 18 November 2013 18:49, Pekka Paalanen <[email protected]> wrote: > > > > > On Mon, 18 Nov 2013 16:54:03 +0100 > > > Marek Ch <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > in reaction to > > > > > > > > http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html > > > > I have got an idea and I like to share it with you and possibly get a > > > > feedback. > > > > > > > > What I was thinking about is: > > > > Add into wl_object another variable for listener (implementation) > that > > > > would be set > > > > when proxy is created (or set to NULL when not needed). In this new > > > > listener would be actions that should be done in display (client's > > > display) > > > > before actual dispatching the event. Example with the global > deletion: > > > > > > > > client recieves global_delete event and in dispatching phase there > would > > > > these steps: > > > > preaction_global_delete(..) // this is new > > > > { mark proxy id as invalid or whatever } // .............. > > > > user_global_delete(..) // this is what > is > > > now > > > > { anything user wants ... } // > ............. > > > > > > > > So, basically, the result would be triggering an action defined by > > > display > > > > (but on client side) on particular event coming. > > > > > > > > Is it any way useful (I can imagine it work for example for the > global > > > > deletion) or is it just silly idea? > > > > > > Hi Marek, > > > > > > I'm not sure I understand what you propose here, but whatever you > > > do client-side will not remove the race, and the race is what > > > requires compositors to turn objects inert instead of just destroying > > > their protocol bookkeeping. > > > > > > The compositor may delete a global, and send the deletion events, > > > but the events could be sitting in the compositor's send buffer, > > > socket's buffers, or the client's receive buffer while the client > > > is happily sending new requests on the deleted objects and not even > > > looking at the incoming events. > > > > > > In fact, the client could be sending the requests even before the > > > compositor decides to the delete global object, and the requests > > > could already be sitting in any of the message buffers while > > > compositor decides the global is now gone. > > > > > > We do need the wl_resource objects alive (but inert) in the server > > > until the client is guaranteed to know that the protocol object is > > > no more. Destroy request is the standard signal for that. > > > > > > > > > Thanks, > > > pq > > > > >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
