Stop log-forwarding thread on IO errors

[MarijnS95]

Fixes #132

When read_line() starts returning Err the current if let Ok condition ignores those, likely causing the loop to spin indefinitely while this function keeps returning errors.

Note that we don't currently store the join handle for this thread anywhere, so won't see the error surface either (just like how the join handle for the main thread is never checked). Perhaps we should call log::error!() to make the user aware that their IO logging has mysteriously terminated.

[MarijnS95]

@rib we probably want to have this in so that I can test rustix on top.

[rib]

Yeah I suppose it's a bit more faff, but it could be nice if we'd log some kind of clue if you hit a spurious error here. If you want to leave that for a separate follow up that's ok though.

Not required but it could also be nice to share a utility for spawning this stdio thread since the code is identical between the two backends.

[MarijnS95]

but it could be nice if we'd log some kind of clue if you hit a spurious error here

Done.

If you want to leave that for a separate follow up that's ok though.

Let's leave stopping+joining the thread for a followup, as we'd have to close stdin/stdout - hoping they haven't been dup2()'d elsewhere - to trigger a len == 0read and exit the thread before calling.join()`.

Not required but it could also be nice to share a utility for spawning this stdio thread since the code is identical between the two backends.

Done, good idea. The util module already exists for exactly this purpose anyway.

[rib]

Even though this was originally proposed in #145 I guess it makes sense to just name this thread here while creating a shared utility for spawning the stdio thread.

This looks good to me, thanks.

[MarijnS95]

Yeah I hope @fornwall doesn't mind some preliminary conflict resolution... Though I can revert it.

[fornwall]

Yeah I hope @fornwall doesn't mind some preliminary conflict resolution... Though I can revert it.

Absolutely no problem, I'll fix!