App freezes when too much data is written to stdout (in one runloop iteration?)

[mallman]

App freezes when too much data is written to stdout (in one runloop iteration?)

[ActuallyTaylor]

This has been implemented into the main branch of the repository with the commit b0fece6.

[mallman]

I'll also note I haven't had this problem with stderr, but that may just be because I'm not writing to stderr enough.

[ActuallyTaylor]

I’m happy that the the product is exactly what you’re looking for!

This is an interesting issue, I can definitely look more into it and get it resolved.

To help out, do you have any simplified code that causes this issue?

[mallman]

I’m happy that the the product is exactly what you’re looking for!

This is an interesting issue, I can definitely look more into it and get it resolved.

To help out, do you have any simplified code that causes this issue?

I do not ATM. However, let me see what I can put together...

[mallman]

So the issue actually has nothing to do with concurrency. I can reproduce the app freeze just by printing enough data on the main thread.

Now it looks like the issue has something to do with buffering. I'm guessing some buffer is getting full, and it needs to be read and flushed or the thread blocks.

I will upload a sample app shortly. It's called Hydrogen Bomb 😆.

[mallman]

Here's my app:

https://github.com/mallman/HydrogenBomb

I've actually only torn out Logger.swift from HydrogenReporter. I needed to do that to fiddle with it. If you do a diff on your source class, you will see two lines difference. (Sorry for the annoyance.)

The most significant difference is at

https://github.com/mallman/HydrogenBomb/blob/2af959e6239223cd795af01c644f6d43503c75fc/HydrogenBomb/Logger.swift#L222

If you uncomment that line, the app does not freeze anymore, however the output is buffered. That's not optimal either.

Note the comment at

https://github.com/mallman/HydrogenBomb/blob/master/HydrogenBomb/HydrogenBomb.swift#L23-L25

is key to triggering (or not) this issue. At least on my computer, an M1 running Ventura 13.5, the conditions stated for triggering or not triggering the issue are valid.

I hope you are able to reproduce the issue on your Mac. If not, try increasing the number of iterations in the loop.

Let me know if I can help in any other way.

Thank you.

[ActuallyTaylor]

Thank you a ton for all of this! I will check out HydrogenBomb (love the name 😍) and figure out a way to stop the deadlock from occurring.

Update:
The issue is reproducible so I will do some jumping in to figure out why this is all happening. It is quite interesting that a single iteration is enough to bring it down...

[ActuallyTaylor]

Okay I have been messing with this for an hour ago and I think you are 100% correct about maxing out the buffer for STDOUT. I think the solution here is going to do with either expanding the buffer for STDOUT or working in a solution to flush when the buffer is full. I will do some more research to find a solution.

[mallman]

Hi Taylor,

Have a look at this commit:

https://github.com/mallman/HydrogenBomb/commit/b1616df7a674a041eeb948a86066d1d2b615eed9

I believe this addresses the underlying issue. The original code is trying to read from the same thread (Main) as it is writing. While the main thread is writing in the write loop, the pipe is not being drained. Its buffer becomes full and the writer can no longer write anymore. Meanwhile, the code that's supposed to be draining the pipe is not running because it's running on the main thread. Hence the blocking on IO.

The solution I've taken here is to run the pipe reading code on its own private thread. It can make progress draining the pipe while any other thread is writing. Updates to the published properties are still performed on the main thread—after the main thread completes its current run through the runloop.

Let me know if this sounds right to you. If you agree, I don't believe a PR is necessary. You can make the code changes just by looking at my commit.

Cheers.

(BTW, I verified this worked with stderr as well using this technique for writing to stderr.)

[ActuallyTaylor]

I believe this addresses the underlying issue. The original code is trying to read from the same thread (Main) as it is writing. While the main thread is writing in the write loop, the pipe is not being drained. Its buffer becomes full and the writer can no longer write anymore. Meanwhile, the code that's supposed to be draining the pipe is not running because it's running on the main thread. Hence the blocking on IO.

This really looks great! I will get this threaded implementation added into main. Thank you a ton for the research that you did to figure this out. From the research I did, this seems like a good solution to the clogged pipe issue that seemed to have been causing this.