Serial Interrupt in OpenGL, which structure to go?

Question

I'm writing an OpenGL software which is driven by UART(serial with help of Boost::asio) in C++ under Linux.

I am currently done with receiving and process data, and ready to visualize it with OpenGL. This question may not be limited with OpenGL, anyway my question is :

How do I call OpenGL drawing function from UART callback function?

Of course, I should be able to get it running by:

1. Using any of IPC(PIPE, socket, semaphore) methods
2. Pass the OpenGL drawing function or its class as a variable to the UART callback
3. Putting everything in one class

I've run into so many similar cases, and implemented in different ways. But I can't still figure out what is THE proper answer.

I personally don't like PIPEs or file IO IPCs, only remaining option is socket, semaphore and shared memory which I've always been using.

Answer 1

How do I call OpenGL drawing function from UART callback function?

Don't.

One should draw only from the drawing handler. Serial I/O should be treated like every other input: Process it in the event loop, or the idle handler, use the received data to update variables representing the new state and issue a redraw.

It's not a tty, but a Linux evdev, but the general idea remains the same: This is a small demo program that shows how to read input from a 3D Connextion Space Navigator and process it into a 3D scene rendering it with OpenGL: http://homepages.physik.uni-muenchen.de/~Wolfgang.Draxinger/stuff/spaceball.tar.bz2

Answer 2

Depends on the application, of course.

It does make much sense for a serial comm callback function to access OpenGL state, but if you're doing a prototype/proof-of-concept, why make your job harder?

Shared memory is a good option; the callback can put the data somewhere, trigger the drawing thread and wait for it to finish. (And this is only one step away from the callback calling the drawing function itself.)

Though I might prefer message passing. When the data is received, the callback can pack and send (copy) it to the drawing thread, who can draw it upon receival. This would have the added benefit of the UART code not waiting on the drawing code, though this is unlikely to be an issue given OpenGL's speed, especially compared to serial communication.