Open BurntSushi opened 8 years ago
For the time being, I ended up just implementing Terminal
with my own type. That allowed me to move forward. See: https://github.com/BurntSushi/xrep/blob/2bda77c414d113b3640b372afffc781a2fe56e6d/src/terminal.rs
Actually, I've been trying to make a new interface that acts more like std::io::stdin
. That is, just have a global "terminal" (although I'd still probably have a way for users to create "mock" terminals for testing). Now that I've submitted my thesis, I'm actually going to make a serious attempt at tackling this. It's not so straight forward because I'd like to support per-thread buffering to avoid crappy interleaved output.
My particular pattern is, "write output to a String
in memory, then later output that String
to stdout
." Would your revisions still support that?
(Specifically, I need a way to write the output of some work without having to do synchronization on each call to print something. I'm happy to trade the memory required to do it.)
One of the feature's I'm working on is the ability to create fully buffered terminal handles that flush on drop. This way, one can build up a nice colored message and have it displayed all at once instead of getting interleaved with messages from other threads.
Would like to hop on this issue with getting Sync support on StdoutTerminal since it's along the same lines of multithreaded support. I wanted color support in a simple logger and it needed to be Send + Sync. A workaround is just wrapping it in a mutex but that's really overkill.
@mooman219 I don't think making StdoutTerminal
be Sync
is related to the specific problem in this ticket, and if one did make it Sync
, I imagine it would use a mutex internally anyway. See how Stdout
is handled in the standard library, for example.
I wouldn't make it Sync. Instead, I'd make creating multiple terminal "handles" cheep. Unfortunately, every time I approach this project, I get stumped trying to figure out the best way to do this on Windows. Ideally, I'd like multi-process programs like cargo to not miscolor error messages.
@BurntSushi Apologies, it felt like it fit under the title and didn't want to little issues on here.
@Stebalien Sounds good to me! I'm quite extremely new to Rust and have been battling it on concurrency lately.
@Stebalien First off, thank you for maintaining this wonderful library. :-)
I came across a particular issue with the current API. Specifically,
TerminfoTerminal::new_with_terminfo
takes ownership over aTermInfo
. Even thoughTermInfo
is never mutated by aTerminfoTerminal
, aTermInfo
cannot be reused across multipleTerminfoTerminal
values. In particular, the only way to amortize the cost of building aTermInfo
is toclone
it, but even this can be costly.I'm not sure what the right API is, but I will note that using
Arc
solves my specific problem (which permits very cheap multithreaded read-only access).There are potentially many other solutions, all with their own downsides:
Arc<TermInfo>
instead ofTermInfo
, but this feels a little strange to me.<T: AsRef<TermInfo>>
. This meansTermInfoTerminal
will need to grow a type parameter.TermInfo
and require that. This also requires an additional type parameter.TermInfo
an opaque struct and use anArc
internally, which will make cloning trivially cheap.Other ideas? Thoughts?