[RFC] Object's pre-actions

[Pekka Paalanen]

On Mon, 18 Nov 2013 16:54:03 +0100
Marek Ch <mchqwerty at gmail.com> 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