-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
better support for multithreaded programs #64
Comments
For the time being, I ended up just implementing |
Actually, I've been trying to make a new interface that acts more like |
My particular pattern is, "write output to a |
(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 |
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?
The text was updated successfully, but these errors were encountered: