Add material to stdio handling

[mahkoh]

No description provided.

[mahkoh]

And here is how you would handle #899 (comment) with this design:

Since you're writing a TUI, you're interacting with fds 0 and 1 directly anyway. Therefore, at the start of your program, you set thread::set_stdout to io::Sink and thread::set_stderr to a log file.

Similarly this allows --test to properly capture not only the output of tests but also the output of threads spawned by the tests.

[l0kod]

Unfortunately, the Windows console do not make Write nor Read usable in a generic way.

cc #972

[mahkoh]

This RFC does not touch the raw versions.

[reem]

I might just not understand some fundamental limitation of the design space, but I'm curious why concurrent synchronization is being used (Arc and Mutex) to control a thread-local variable, which seems to only be modifiable from one thread. As a result, Rc and RefCell could be used, which would be more efficient.

[mahkoh]

@reem

I'm curious why concurrent synchronization is being used

+Unless other streams or another buffer mode has been explicitly specified via
+the thread-builder, these settings will be inherited by child-threads.

[reem]

Ah, I figured I had just missed something.

[aturon]

I think making println and panic reference a thread-local, inherited, overridable notion of stdout and stderr is a good move, for composability/capture purposes. So 👍 to the overall idea here.

One question: are the raw versions tied to the process-level handles? That is, does std give you any way to get at these underlying handles?

I'm a little unsure about the exact signatures/locations of some of the functions proposed here, but I want to think a bit more about a possible alternative for concrete comparison. I'll try to do so soon.

[liigo]

Why lock on thread local streams?

[mahkoh]

They are not thread local.

[mahkoh]

@aturon

One question: are the raw versions tied to the process-level handles? That is, does std give you any way to get at these underlying handles?

This RFC does not make any changes to the raw section which is marked as a sketch anyway. Raw handles will have to refer to the 0, 1, 2 fds on unix directly.

[Ericson2314]

Is there any way to make some of this more opt-in so threads that don't do IO don't need to carry all this baggage around? All the behind the signs dynamic dispatch and thread local stuff reminds me a bit of the old green/native IO system.

I'm of the opinion that the standard streams are classic stupid arbitrary "singletons", and thus just plain bad design and holdovers from another era. The fact that we need to such things as are proposed here to fix them I take is evidence of the fact. I rather hook up panicking to the liblog infrastructure than bake this stuff into std::thread.

[mahkoh]

all this baggage around?

Four pointers and a few atomic operations when you create a thread.

classic stupid arbitrary "singletons"

You're suggesting removing thread local storage and println from the language. That's an interesting thought.

[aturon]

RFC issue #1050