> > Please look next at manual page "timer_create.2" . This is all new Posix > compliance tools. There is an example provided. Apparently, the call > even allows you to define several types of clocks and event reporting. I > don't understand "threads" and "virtual" stuff, but I do understand a > "process." > I looked at the manual page. Yes, it is all POSIX and in general if your application is sticking with unix, you want to stick to POSIX pieces of the glibc and the kernel. This particular piece of work, as the manual page states, is a mix of kernel work and some glibc pieces. This is very good in my opinion (to have most of it in glibc), as the user gets a lot of say in what happens during execution. There is an example given, but I do not think it would be instructive for you given that you do not touch C or system programming. But, in a nutshell, the example shows how a signal handler is established (in a special way) to trap timer expiration events for this particular process alone. It sets the signal handler and first blocks trapping of that signal by the handler. It gives the process time to establish the timer; which is the meanigful thing to do. Then, it unblocks the signal handling and sends the main process work to sleep. The timer will have expired when the process wakes up. The pending signal will "fall" into the handler when that happens. It works as expected. It is not the most instructive example, but it does do what it promises. I tried it as is and I tried it without blocking the signal trapping at all. In the former case (original code), it waited for 1 second before it trapped the signal due to the timer having expired. In that latter, the handler invoked immediately (after the 100 nanoseconds I had specified) while the process was starting to go to sleep for a second. One more (possibly instructive to you) point. If you follow this model of using HRTs and want to work with signals that are picked from specific timers, you will have to provide handler functions. Those become detached POSIX threads (is my understanding) to execute the handler code. There is no other way, if you think about it. You can certainly achieve realtimeness that way. Or you can engineer your UI so that it traps signals and then re-freshes the screen at constant framerate. A thread in the backend can do all intensive work and set a flag for what it is done. The main loop of the UI keeps checking the flag and draws new things when the flag is set and it unsets it. Really easy to program... > Using freepascal 3.0.0 to access C library calls isn't hard. But the > timer_create manpage also indicates a needed link to "-lrt" . The > freepascal team has added a lot of Unix and Linux calls over the years, > but not this one yet. I've done this before, and that's why I got old. > I had to link with -lrt (of course). It does not matter what the Pascal compiler and linker invokation do. I would make sure the Pascal compiler can produce compiled object code (.o files) and then link with the linker externally or just link with gcc (the C compiler/linker stript). > Understanding the XForms-toolkit somewhat, I do think this approach is > much better precision than the legacy timeout functions used in the > toolkit. And the XForms maintainer rightly criticized my using a system > Sleep call to get better accuracy, since it blocked XWindow events too. > So I think this is a very versatile feature to play with drawing complex > functions on a screen stripchart. > Yes, do not sleep the main process that handles X window events... You will get a freeze and then possibly a pile of events to be handled at once. You typically want your UI to run in semi real-time and have all processing done in the background; this can include UI event-handling. Most people do not concern themselves with realtimeness issues and make the main code the UI event handler. I think this is bad practice, but it has a low barrier to entry for programmers and for non-intesive work. > When I get a decent set of software I'll try put it on a little web > site. Even try put up a few binary programs so you don't have to work so > hard to figure what I'm talking about. Thanks for trying. > Use Github. I do use it for such things. I hope I had shed some light in this for you and I have not wasted anybody else's time with yet another pedantic post.