I have a standard glut implementation. The display function redraws each object, but I need a constant update on certain values of each object. As it is, the only way I can think to do this is to spawn a thread to handle the updating. However, I can't use glutPostRedisplay() from a different thread to get glut to refresh the window. What is a good way to have a loop to update values alongside the glut loop?
Also, what's the best way to sleep for fractions of seconds (instead of sleep() for whole seconds).
If you need some sort of regular updating, you probably want to set a glutIdleFunc. This is a function that will get called in a loop whenever there are no events coming in to be processed. If you instead want to call something at regular intervals (as opposed to as fast as possible), you might want to try glutTimerFunc which allows you to schedule something to be run by the GLUT loop some number of milliseconds in the future.
As for your second question, if you need to sleep for fractions of seconds, you might want to try usleep for microsecond resolution sleep periods, or nanosleep to specify sleep periods in nanoseconds (though you're not actually going to get nanosecond resolution). I don't know what platform you're on or if these are available on Windows, but they should be available on any POSIX compatible system (Linux, BSD, Mac OS X). But perhaps for your purposes glutTimerFunc will work better.
edit to add: It looks like on Windows you would need to use [Sleep](http://msdn.microsoft.com/en-us/library/ms686298(VS.85%29.aspx) (note the capital S), which takes a time in milliseconds.
Related
I've seen a lot of answers to very similar questions, but they all seem to resort to using something like a sleep(1/n) call at the end of a function or in some cases timing the function and calling sleep((1/n) - functionTime). Surely there is a better way to do this? Modern hardware has access to precise hardware timers that can send an interrupt to the CPU some known number of times per second, is there no way to take advantage of these timers to run a function such as a physics engine update a known, fixed number of times per second from user space code? What I would like to do in particular is, preferably in C or C++, define some function, let's call it foo(), and designate it to be called N times per second. I would want to be able to know that if M seconds have passed, foo will have been called N*M times assuming foo() ran in less than 1/N seconds on average.
There is no standard C API for scheduling calls.
You probably want to have a separate thread that runs every 1/Nth of a second.
In the pthreads world, this can be done with pthread_cond_timedwait. This function expects the absolute time to wake up. In addition, some other thread can wake it up using the condition variable if some unplanned update needs to be made.
In the Windows world you probably need one of the WaitFor<whatever> functions. They expect a relative timeout, so you want to convert absolute time to relative time-interval-from-now yourself. In this case, too, another thread is able to wake you up to perform an urgent update.
The absolute time you need is just the absolute time the previous call was scheduled for, plus 1/Nth of a second. The very first one can be set to the current time just before the call.
I want to have a function that would run every N milliseconds and i want it to run precisely (relatively, i dont need atomic clock precision).
From what i can see, GLib manual says that g_timeout_add() does not guarantee precision and can be delayed due to other events.
Is there any other way to have precise time events with GTK/GLib? I would rather not use platform specific code, as i want my program to work on both Windows and Linux with as few platform related code changes as possible.
How precise is "not atomic clock"? In the end, timing precision is going to be limited by factors like the platform's context-switching behaviour. Unless you're using customer kernels or specialist hardware, there might not be much you can do about that.
g_timeout_add() is doubly problematic, because it's operation is tangled up with the GTK event handling mechanism, which was never designed for precision.
In the end, your best bets might be either
Use a conventional, signal-based timer (e.g., from setitimer), or
Spawn a new thread and just usleep() a fixed time between actions.
Both these approaches are problematic in GTK, because it's hard to update the user interface from outside the GTK main context thread. Some fairly complicated locking and inter-thread communication is usually required.
If practicable -- and I have no idea whether it would be -- I would suggest delegating the timing part to some separate process, and have the GTK application interact with it using, e.g., sockets.
Without more detail g_usleep would probably be your best bet, but keep in mind that it blocks the current thread so if you want other tasks to proceed in parallel you'll need to spawn a new thread to run it in.
I have a tcl/tk with c desktop application, and one of the requirements is to change the system time, in the background there are threads running from the c code, and "after" commands from the tcl code. Whenever I change the time to an earlier time the system hangs
i.e: 05:50:12 -> 05:45:12 also i get weird behavior when going forward in time. I'm running lubuntu. I'm not sure what to do in this situation, I made some test and it seems the after keeps on waiting after i change back in time.
to change the time i use : exec date --set="STRING" from the tcl code
Tcl depends on the system time (converted to seconds from the start of the Unix epoch) increasing fairly close to monotonically for the correct behaviour of a number of things, but most particularly anything in the after command. Internally, after computes the absolute time that an event should happen and only triggers things once that time is reached, so that things being triggered early (which can happen because of various OS events) don't cause problems. If you set the system time back a long way, Tcl will wait until the absolute time is reached anyway, which will look a lot like a hang.
Just synch your clock with NTP (i.e., switch on ntpd) and stop fiddling with the system clock by hand.
I have a GTK window with an image inside of it. I want this image to change. Let's say I have two images, "sun.png" and "moon.png". Once every second, I want to receieve the output of "date -f%l" to get the current hour. If the hour is between 7-19 (7 AM to 7 PM), I want to display sun.png. Else, I want to display moon.png.
Is it possible to have a seperate thread with a while loop in it, that changes the image as the program's running? How would I go about doing this?
I'm writing in C, by the way.
This isn't going to be a complete answer, but it's too long for a comment and it's important.
You definitely do not implement something like this by going into a loop sleeping for one second at a time and calling the external date command and parsing its output to determine what to do next. Not only is this a lot more work than is necessary; more importantly, it will eat your users' batteries for dinner.
Instead, you call gettimeofday or clock_gettime to determine the current time, then compute the next time in the future that the sun/moon image will need to be changed. Then, you sleep the whole interval until that time, i.e. up to 12 hours in a single sleep. If your thread wakes up early (perhaps from signals, etc.) then you just determine, on calling gettimeofday again, that it's not yet time to change, and compute a new duration of time to go back to sleep. This way, the CPU remains completely idle (and can go into powersaving mode) except when there's actually work to be done.
As for whether you can do this with a thread at all in GTK+, I'm pretty sure you can, but I'm not familiar with the GTK+ API.
I want to measure the running time of a specific system call, for example, I want to know a pread need how many time on both CPU and I/O.
Which function should I use?
Now I usetimes, and it works.
gettimeofday is get the current time, and that may not just calculate the running time of a specific process, right?
clock is return the CPU time this program used so far, does this include the I/O time? If there are other programs running, will this influence the time of this function? I mean something like switching running process.
getrusage seems like a ideal one, but it also returns the CPU time of a specific process.
Does anyone know how benchmark tools like iozone calculate system calls time? I've read its code, and still have no idea.
You're looking for times(2).