Absolutely outstanding. Again, sincere thanks. Right now I'm reading "Programming for the Real World; POSIX.4," by Bill O. Gallmeister; Copyright 1995 by O'Reilly & Associates Inc. The book is much clearer than the Linux manpages, and explains why these Posix.4 timers are an important new aspect of Linux (Unix) software. I got the book many years ago when I thought the Linux 2.4 kernel was great. Now seeing industrial linux hardware the size of this book with real-time capabilities, it is a topic worth being aware of I believe. Many years ago I did a lot of "libc" adaptation of signals, semaphores, the UART, etc. in freepascal. It's quite easy really, but I have not yet found what's in librt; I know it comes with libc. Not your (C, C++ programmer) problem at all, just a Pascal problem since I need to know where functions are accessed. As for the stripchart XForms program, you are right, I have a lot to figure out. It still draws reasonably accurate trigometric functions. It will be a great goal to have a useful set to offer. Since you have worked Monte Carlo (random) collision chemical reaction kinetics theory simulations you might like to see how 3 or more sine waves add up graphically. My outdoor long range television antenna is a good oversize model of a molecule, with molecule dipoles instead in the optical wavelength range. Chemistry does not need to be "random." Innovation matters. Iznogoud wrote: >> 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. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >