Consider explicit deletion of stream objects on exit about stdio-mgr HOT 5 OPEN

#3 is sort of related, and on its way to being solved.

I think .close() would have similar effect on memory consumption, as all buffers are released, but worth checking.

from stdio-mgr.

In most modern contexts, for anything but the most ridiculous of large streams, I can't imagine this Issue is likely to be a big issue. Seems very YAGNI.

Especially with the changes from #25 and #26, though -- as you noted at the bottom of #26, the mocked stream objects are now storing internal references to the underlying buffers in some situations, and that could lead to memory accumulation if enough things stay in scope/have references.

from stdio-mgr.

Although -- both RandomTextIO and TeeStdin store a reference to the buffer in ._buf... as long as the (i, o, e) objects remain in scope, I would think they will retain references to their ._bufs the whole time, even after .close() or .detach(), right?

I guess .close() frees the actual buffer memory, so in that case it is just ._closed_buf to worry about in terms of memory consumption.

But for .detach(), I'd think it would still matter -- though, if someone is .detach()-ing, they likely still want to work with the stream data, and so it would probably be a total footgun to wipe the buffer after just a .detach().

So, yeah: just ._closed_buf to worry about, then.

from stdio-mgr.

With #58 switching the persisted-content mechanism from ._closed_buf to a callback, this issue should be moot.

from stdio-mgr.

I think we at least need tests for this, and it turns out to be very important to delete objects when using TemporaryFile and when using the real sys handles.

from stdio-mgr.