On Tue, Oct 13, 2026 at 8:52 AM Mark Brown <[email protected]> wrote:
>
> Python's text streams are not thread safe. If two threads write to
> sys.stdout at the same time the stream's internal buffer can be
> corrupted, resulting in lost output and runs of NUL bytes or heap
> garbage being written in its place. This isn't an issue currently, but
> will be when we implement support for parallel test execution.
>
> Add a lock to kunit_printer which Printer.print() takes around each
Firstly, thanks for taking on test parallelization!
In March 2022, I'd written a proof of concept that worked, it just
leaked some memory on the C side so I never shared it.
(Instead of using the existing test filter glob, I'd added the ability
to specify arbitrary test indices to run a slice of tests)
I'd have to reacquaint myself with the code to actually review the series.
But one thing that sticks out immediately is, my version had added
this new type to avoid the need for any locking:
+class BufferPrinter(Printer):
+ """Like Printer, but only prints to an in-memory buffer."""
+
+ def __init__(self, parent: Printer):
+ """Creates a new printer that inherits parent's
settings (use_color)."""
+ buf = io.StringIO()
+ super().__init__(buf)
+ self._use_color = parent._use_color
+
+ self._parent = parent
+ self._buf = buf
+
+ def close(self):
+ """Prints the contents to the parent printer and frees
memory."""
+ self._parent.print(self._buf.getvalue().rstrip('\n'))
+ self._buf.close()
+
It required passing along kunit_printer.Printer objects to more
functions, but I think it might be a cleaner end result.
By explicitly calling `close()`, we could control when exactly output
gets flushed so we can avoid weird interleaving.
It seems in a later patch, you write each kernel's output to a file to
get the same effect, but an object like this could be used in more
places.
Thoughts?
-Daniel
