The copy-on-write lock is just an atomic reference count that we put in shared memory when doing multi-process.
On Wed, Jul 2, 2014 at 5:49 PM, Patrick Walton <pcwal...@mozilla.com> wrote: > On 7/2/14 5:51 AM, Nicolas Silva wrote: > >> In the "internal buffer" scenario, we don't need to create a new shmem or >> swap back and forth between the front and back textures if the compositor >> is done uploading the texture. So we have a lock that the content thread >> takes when painting and that is released by the compositor after the >> texture is uploaded. Next time a tile needs to be painted we only create a >> back buffer if the front buffer's lock is still taken, in which case we >> copy the front tile's content into the back and repaint the damaged region >> (this is the copy-on-write I was referring to). >> > > How do you do this locking and reference counting in a multiprocess > scenario? > > Patrick > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
