curses to OpenGL than a GUI toolkit. NTK, the Ncurses ToolKit, would be
more like Gtk+ in it's scope. Your solution is intriguing and I'll take a
closer look at it.
On Tue, Nov 19, 2013 at 3:29 PM, Jsor wrote:
The way I solved OpenGL in a multi-threaded, concurrent environment was to
have a "master" goroutine that formally owned the context, and was
perpetually locked in a loop over a chan func(). While you can do any
calculations or whathaveyou outside the thread/goroutine, to execute
instructions on the context itself, you send a func() over a channel to the
main context, and the context thread will execute it. A simple/naive
implementation is just
runtime.LockOSThread()
whateverImUsing.MakeContextCurrent()
for f := range instructionChan {
f()
}
Though often you need a bit more control than that (my rendering system
uses a select statement that is set to render the scene at set intervals
between executing functions, for instance), but the gist remains the same.
You do have to be aware that instructions may not be executed immediately,
of course, but it works pretty well and the delay in execution is usually
fairly negligible (at the very least it's not too much worse than any OTHER
non-professional implementation of an asynchronous rendering system).
You may want to handle I/O separately, but with most setups it's not
strictly possible (the event callbacks for the input are going to be
executed in the context no matter what), but you can keep them conceptually
separate if you introduce a one-way dependency. For instance, I have an
input handler that tags along with my renderer as a separate subsystem, and
reading the code it feels like they're mostly independent of each other,
but in reality 90% of the "input handler's" job is feeding new callback
registration requests to the renderer's function channel as is necessary.
Most of the actual work is executed in the renderer's thread/goroutine even
though the code is in the input handler. (And the rendering system is
agnostic to the input handler's existence).
I don't know how much of this is immediately applicable to ncurses, or
gtk+, or whatever else, but from the gist I got from the thread they seem
similar in concept.
I'm sure it may be theoretically possible to do I/O concurrently, but it
would probably have to be built ground-up with it in mind, not just a
wrapper around an existing library. Rob wrote an article on a concurrent
window system here: http://swtch.com/~rsc/thread/cws.pdf
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-nuts/q0bYe7CA_y4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--The way I solved OpenGL in a multi-threaded, concurrent environment was to
have a "master" goroutine that formally owned the context, and was
perpetually locked in a loop over a chan func(). While you can do any
calculations or whathaveyou outside the thread/goroutine, to execute
instructions on the context itself, you send a func() over a channel to the
main context, and the context thread will execute it. A simple/naive
implementation is just
runtime.LockOSThread()
whateverImUsing.MakeContextCurrent()
for f := range instructionChan {
f()
}
Though often you need a bit more control than that (my rendering system
uses a select statement that is set to render the scene at set intervals
between executing functions, for instance), but the gist remains the same.
You do have to be aware that instructions may not be executed immediately,
of course, but it works pretty well and the delay in execution is usually
fairly negligible (at the very least it's not too much worse than any OTHER
non-professional implementation of an asynchronous rendering system).
You may want to handle I/O separately, but with most setups it's not
strictly possible (the event callbacks for the input are going to be
executed in the context no matter what), but you can keep them conceptually
separate if you introduce a one-way dependency. For instance, I have an
input handler that tags along with my renderer as a separate subsystem, and
reading the code it feels like they're mostly independent of each other,
but in reality 90% of the "input handler's" job is feeding new callback
registration requests to the renderer's function channel as is necessary.
Most of the actual work is executed in the renderer's thread/goroutine even
though the code is in the input handler. (And the rendering system is
agnostic to the input handler's existence).
I don't know how much of this is immediately applicable to ncurses, or
gtk+, or whatever else, but from the gist I got from the thread they seem
similar in concept.
I'm sure it may be theoretically possible to do I/O concurrently, but it
would probably have to be built ground-up with it in mind, not just a
wrapper around an existing library. Rob wrote an article on a concurrent
window system here: http://swtch.com/~rsc/thread/cws.pdf
On Sunday, November 17, 2013 1:14:40 AM UTC-7, Jesse van den Kieboom wrote:
I only have experience with gtk+ so I'm no authority, but. All gui
libraries that I know are not made to be thread safe, but should be called
from the same thread it was initialized from. This works well if you
instruct users about it properly because in most languages you control
threads explicitly and you know how to synchronize between them. In gtk+
(and I see something similar in the go qml bindings) you usually install a
callback which is called when the gui main loop gets idle. The callback is
executed in the context of the main loop.
The thing with go is that threads can be created all the time and you
don't even know it. go routines are such an integral part of the language,
that I as a user would expected that gui libraries take care of allowing me
to call their code from multiple go routines. You can check
https://github.com/niemeyer/qml to see how you can do that in a
relatively nice way without locking all the time.
You received this message because you are subscribed to a topic in theI only have experience with gtk+ so I'm no authority, but. All gui
libraries that I know are not made to be thread safe, but should be called
from the same thread it was initialized from. This works well if you
instruct users about it properly because in most languages you control
threads explicitly and you know how to synchronize between them. In gtk+
(and I see something similar in the go qml bindings) you usually install a
callback which is called when the gui main loop gets idle. The callback is
executed in the context of the main loop.
The thing with go is that threads can be created all the time and you
don't even know it. go routines are such an integral part of the language,
that I as a user would expected that gui libraries take care of allowing me
to call their code from multiple go routines. You can check
https://github.com/niemeyer/qml to see how you can do that in a
relatively nice way without locking all the time.
On Sunday, November 17, 2013 12:06:19 AM UTC+1, Rob Thornton wrote:
I know of its use in a few games. It would be natural for game related
events and drawing to the screen to be handled separately in a goroutine
and input in another.
Amusingly, the closest date I could find for the initial release of
curses was "around 1980" which makes me only slightly older than the
library. ;)
I know of its use in a few games. It would be natural for game related
events and drawing to the screen to be handled separately in a goroutine
and input in another.
Amusingly, the closest date I could find for the initial release of
curses was "around 1980" which makes me only slightly older than the
library. ;)
On Saturday, 16 November 2013 14:49:54 UTC-8, RickyS wrote:
What could you do concurrently or in parallel, since the codebase is
still 'single-threaded'?
That is, could curses start prompting the user for input while it draws
the screen? Or something?
I would guess there is nothing you could do that was correct and
reliable.
In my memory the old thing would have to wait until the i/o was done,
anyway.
Perhaps you could reject any call that was not from the starting thread?
I guess the best is provide help for item 2).
Are there startups basing their product on ncurses?
It was designed originally for the vt100, hardware from 30 years ago.
The software is older than you (probably) are.
Best of luck.
--What could you do concurrently or in parallel, since the codebase is
still 'single-threaded'?
That is, could curses start prompting the user for input while it draws
the screen? Or something?
I would guess there is nothing you could do that was correct and
reliable.
In my memory the old thing would have to wait until the i/o was done,
anyway.
Perhaps you could reject any call that was not from the starting thread?
I guess the best is provide help for item 2).
Are there startups basing their product on ncurses?
It was designed originally for the vt100, hardware from 30 years ago.
The software is older than you (probably) are.
Best of luck.
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-nuts/q0bYe7CA_y4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
