Relegate the on-close for emergencies

[cbm755]

@alexvong1995 how about this?

We do the waiting and verbosity etc in the explicit reset case. Then the onClose stuff becomes kind of an emergency catch-all for situations (like "pkg unload"). To me, this makes it clear, that its pkg unload's fault for not giving us a hook ;-)

[cbm755]

So can you look over this one? It builds on top of your commit, but restores things to be closer to how they were before @mtmiller split off python_ipc_popen2_reset.m in dfe236d471989f8eb062ab56935bed8866b9700f

So in the explicit reset situation, the onCleanup code becomes a no-op.

[mmuetzel]

its pkg unload's fault for not giving us a hook

Not sure what exactly you need. But the PKG_DEL scripts might do something similar. See: https://docs.octave.org/latest/Creating-Packages.html Essentially, these scripts are executed whenever the path containing them is removed from Octave's load path. That is happening on pkg unload. (But admittedly, it's not a real hook but just a script.) Maybe you could use (mlocked) functions that keep some values stored in persistent variables if you need to access them from the PKG_DEL script?

As a side note (and I don't know if that matters here): Persistent variables are cleared whenever a function gets reparsed. There are no guarantees when that is happening (unless you mlock that function).

[cbm755]

Persistent variables are cleared whenever a function gets reparsed. There are no guarantees when that is happening (unless you mlock that function).

Thanks @mmuetzel. As long as the onCleanup triggers, then I think that's fine and how we want it. The onCleanup closes the file handles. And then next symbolic command would rebuild the pipe.