> 
> 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.