I maintain goncurses[1] and I am appealing to those of who who would be
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
called concurrently.

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?

[1] http://code.google.com/p/goncurses

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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 6 | next ›
Discussion Overview
groupgolang-nuts @
postedNov 16, '13 at 10:34p
activeNov 20, '13 at 4:09p



site design / logo © 2022 Grokbase