GTK: Avoid theoretical access to a destroyed object on async paste

GTK clipboard is asynchronous, which means that the answer to a request
can theoretically arrive at any moment in the future after the request.

This poses a problem as the receiving code has to make sure the object
on which the paste was requested still actually exists by the time the
response arrives, as it could have been destroyed in the meantime.

A possible solution is to add a reference to the object during the
query so that it is kept alive as needed.  However, this means that if
the paste request really takes a long time to get answered, it can
prevent the application from destroying the object explicitly,
possibly at the user's request.

So instead, use a helper object adding a weak reference to the object,
and only process the paste request response if the object is still
alive then.

All this is fairly theoretical though, as in practice paste is
generally not effectively asynchronous (GTK tries and calls the
response callback directly in the request call when possible), and when
it is effectively asynchronous, it generally is very fast.

0 files changed, 0 insertions, 0 deletions