Closed MarijnS95 closed 9 months ago
@rib we probably want to have this in so that I can test rustix
on top.
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.
Yeah I hope @fornwall doesn't mind some preliminary conflict resolution... Though I can revert it.
Yeah I hope @fornwall doesn't mind some preliminary conflict resolution... Though I can revert it.
Absolutely no problem, I'll fix!
Fixes #132
When
read_line()
starts returningErr
the currentif let Ok
condition ignores those, likely causing theloop
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.