[Live-devel] File handle leak in slightly modified testMPEG2TransportStreamer

[Warren Young]

On 1/30/2014 17:44, Ross Finlayson wrote:
> I haven't seen this at all with the unmodified
> "testMPEGTransportStreamer" code - which is what you should be using to
> test this.

My point in asking is to learn why behavior changes when you change that 
one aspect of the existing code.

> At that time, "videoSink->source()" gets
> set to NULL.

I see.  You're zeroing a pointer to memory that is still in use, without 
deleting it.  This in turn is why there has to be a separate pointer: 
because you can't currently depend on the sink to keep it through the 
call to afterPlaying().

Given that, why doesn't the sink take full ownership of the source 
object once you pass it to startPlaying()?  Then it will be free to 
delete it before zeroing the pointer, so afterPlaying() doesn't need to 
call Medium::close() on it at all.  Then there is no need for this extra 
global pointer.

Obviously a few globals aren't a big problem in a tiny little example 
program.  I care because the design constraints that require a program 
to keep track of this videoSource object in a 158 line program also 
apply in a 158,000 line program.

I hope I don't need to defend state space reduction and encapsulation in 
2014.