Xpra: Ticket #1431: pixel data race condition - unnecessary copy?

During testing for #1423, it seemed possible for the window pixels data to go away from underneath us whilst in the encode thread.

r14991 tries to fix this by always making copies of the pixel data when we "process_damage_region", which we already did for freezing video frames that get delayed for av-sync.

In 99% of the non-av-sync cases, this is a complete waste of CPU cycles because there will be no concurrent access and destruction.

Assuming this is really needed (not 100% sure yet), we should be able to replace this with a simple lock and either wait for the lock to be freed to free the xshm backing (potentially stalling the UI thread..) or just defer it. ("dealloc" should be enough).



Tue, 14 Feb 2017 14:15:31 GMT - Antoine Martin: status changed; resolution set

Damn, I can no longer reproduce the crash - which must have been caused by something else (a bug in #1423 perhaps)

So r15064 reverts this change and this will need to be backported too.


Tue, 14 Feb 2017 14:22:47 GMT - Antoine Martin:

More details on why this is safe as it is:

Sub-images (used by the scrolling code) are also safe as the encoder for each sub-image is called from within the encoding function for the parent image (which owns the pixel memory).


Sat, 23 Jan 2021 05:24:08 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1431