Ok, this could be really hard, or really easy, here’s my problem,I have data comming in through an ethernet cable from a device, this is done with sockets, fyi, the data is constantly flowing

I am not sure with how the mainLoop of GL is set up, if it would just be a good idea to thread the whole handeling of the socket data, or not. Frankly, i have tried both, threading, and setting the idlefunc to the method that opens and handles the data.

also, in the function that handels the IO im just called glutpostdisplay, and my glutdisplayfunc is the one that draws everything based on the data.

I have a feeling that im screwing up the event queue somehow, any suggestions?

ok ive have done some more reading, it looks like calling glutpostdisplay from a thread just wont cut it…tell me if this sounds right…ill have a bool or something in the IO tread, and when new things are ready to be drawn, i set it to true…in my display func, which is also my glutidlefunc, i check for that bool, and if it is true, set, the bool back to false, and draw teh new data, since, there is only one thing here, i shouldnt even have to mutext it…right???

Well if you have a display thread and an i/o thread you need to make sure there is communication of data between them and all the rendering gets done in the display thread. Whether you need synchronization and buffered communication between them is for you to determine.

If you’re not threaded then just calling the i/o in a glut callback is fine. Just be aware that you’re not threaded doing that unless you launch a thread in there (not recommended).

If you are threaded the you probably want to perform a data copy, or bool IPC in a callback (a bool would be a synchronization). You could make it 2-way or not depending on your circumstances.

There are many strategies depending on the nature of the data and the timing & relative performance.

yeah, thats what i thought, right now, im just using the stl swap() function, because that is atomic, but anyway, the tread will swap, and the display with swap, and there is a conditional check in each thing, thus it is syncronized, I think i still might have to get a buffer going though, cause the data is comming it at around 75 frames of data per second…we shall see, thanks for the help

The STL swap() function is not atomic.

The simplest approach to synchronisation is using a mutex to protect access to shared variables. Unfortunately the API is different for each operating system.

If you want a truly atomic swap, you’ll have to write it yourself with assembler, but that’s obviously architecture dependant, and also compiler dependant :frowning:

There is a nice cross-platform thread class at
Cross-platform thread class

Part of it is a Mutex class which I’ve used on Windows and various Linux. It’s just a couple of header files so it’s simple to use. Though for the Thread class I’ve had to fix a couple syntax things for the newer (and stricter) g++.