better at concurrency than myself. Almost every function in the curses
library reads or writes to the underlying C data structures. Curses, and
its more modern descendants, were not built with concurrency in mind.
ncurses has added some built-in functions which can be used to wrap any
other function in the library with a global lock/mutex but from research
I've done it's not recommended to use/rely on them as there is still the
potential for race conditions/data corruption (I'm not exactly sure why).
Thus, I've had two options:
1) Wrap every function in a global mutex (well over 100).
2) Instruct users to wrap any curses functions within some kind of
synchronization (channel or mutex) to ensure no curses functions are ever
I have opted, so far, to take option 2 and do so in my own code. I am
worried that wrapping certain functions, especially those which are
blocking (buffered input comes to mind), will cause bottlenecks/deadlocks.
Is my reasoning sound? Is there a better way I should be handling this?
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.