Flush cout to notebook during code execution (pyROOT issue?)

[will-cern]

Feature description

Hello. I've seen this being requested a few times by others over the years, and I want to throw in my request for this feature, as we are getting close to having tooling for advanced statistical analysis where it is normal for things to take a bit of time to execute, and in a terminal there is periodic printout to show progress but this is not being displayed in a jupyter notebook. A minimal reproducer could perhaps be simply:

import ROOT
ROOT.gInterpreter.ProcessLine("""
for(int i=0;i<5;i++) {
std::cerr << i << std::endl << std::flush;
sleep(1);
}
""")

if you run this in the terminal, you see the output as it runs. In a notebook, you see it only once execution completes.
It would be really really really nice if we could have the output in the notebook as it runs, even if this is an experimental feature for now?? Pllleeeeeeaaaasee! :)

Alternatives considered

No response

Additional context

No response

[guitargeek]

Hi @will-cern! Thanks for opening an issue about this real pain point.

The problem is that the C++ output is not directly written to the Python output stream, but there is an output polling thread that collects the C++ output and flushes it to Python output after running the cell.

Step one to fix it is to have the output polling thread flush partial output whenever it does its syncup. This is trivial to implement in JupyROOT.

Step two is to release the Python GIL for these expensive C++ functions where we want live output, and this can't be done in general. Releasing the GIL has quite some Python overhead, so we generally don't do this for PyROOT functions. You can however manually tell PyROOT to release the GIL for a given function by setting the __release_gil__ attribute. So we have to set this for all C++ functions where we care about live output, starting with the TInterpreter entry points.

I have implemented both in this PR:

• [Python] Stream notebook cell output instead of buffering until done #22199

I understand that it is annoying that we have to manually flag the GIL-release on the Python side on a case-by-case basis. That's why we're looking into leveraging compiler annotations to steer such flags directly from the C++ function declaration (there is an issue #21618 about this, motivated by the ownership semantics problem).

So what do you think about having a custom annotation like _release_python_gil, that can be used like this?

RELEASE_PYTHON_GIL void long_running_function() {
   // do stuff
}

And then once Python gets rid of the GIL when making its free-threading mode default, this would not be needed anymore at all.