mir_connection_release does not free associated surfaces

[Kevin DuBois]

mir_surface_release() is needed before mir_connection_release() in order to clean up resources on the client side. This wishlist bug could be resolved by either 1) documenting this a bit better or 2) making it so that resources associated with the connection are cleaned up on mir_connection_release

[Alan Griffiths (alan-griffiths)]

My preference is for the client code being responsible for cleaning up any resources it allocates. (And not having mir_connection_release() do it implicitly - although it might make sense to have the latter block while surfaces are held.)

[Daniel van Vugt (vanvugt)]

Yes, the client is responsible. But MirSurface is really a subordinate object to MirConnection. If you destroy the MirConnection then I think it's just good API design to automatically destroy any remaining surfaces owned by that connection.

[Alan Griffiths (alan-griffiths)]

I'm not such a fan of things happening "by magic".

If a client hasn't released the surfaces when it disconnects it is buggy (either because it always leaks, or because there is a race condition and the release is yet to happen).

We should be making it easy for developers of clients to detect bugs - not concealing the effects of their bugs.

If we do as you suggest then leaky clients appear to work, and racy ones intermittently hit undefined behaviour by releasing tie surface for a second time.

If we were to block pending all surfaces closed, then racy clients appear to work and leaky ones hang.

If we "assert" that all surfaces have been closed, then both types of bug are detected early. I'm tempted.

[Alexandros Frantzis (afrantzis)]

Fixed in mir/devel r1700, released in 0.3.0

[Daniel van Vugt (vanvugt)]

Branch 0.3 happened on revision 1691 so the fix actually first landed in series 0.4 but it appears to have been backported to the 0.3 series immediately before tag 0.3.0 so close enough...