ah, sending two different messages with the same subject - that's bound to get you an answer only for one of them....
On Fri, 2006-12-15 at 11:16 -0800, Barry Gershenfeld wrote: > I want my program to keep a rough awareness of time passing, so I can > schedule certain events every so often. I don't want to poll the clock, so > I choose to have an interrupt that increments a counter. This has always > served well in microprocessors, and as this is an embedded linux app, I want > to do the same thing here. So I pull out the API reference, the book that > started LPSG, "Linux Application Development" and start reading. > > There is an interval timer for this; it uses SIGALRM, and, it is pointed out > most everywhere you look, this interferes with the alarm() system call, and > by indirection, the sleep() call. it is a no-no to use those signals without very clear understanding of what they do, and what they do not do. - since there is only one ALRM signal, there can only be one "guy" who catches it. if two try to catch it - you're in a mess. - thus, any use of such signals is not friendly to multi-threaded programs. in particular, caling sleep() from two seperate threads of a program will not work. - normal signals are lossy - if you got a signal, you cannot be sure that you didn't miss 3 others. if the system delivered the same signal type to your program before your signal handler got invoked - your signal handler may only be invoked once. - signals are asynchronous with regards to your code. - signal handlers are very limited in what they allow you to do before your program becomes un-portable, or stops working. now, if you're already in user-space land, why do you try to still work with interrupt-like constructs? there are often better ways. what the better ways are, depends on the type of program you are writing, because, unlike what we were all lead to believe, in unix - not everything is a file. for example, if your program is multi-threaded - have one thread handle those time-based tasks. if your program is select-based - use a proper timeout to handle those time-based tasks (unless you need a very fine-grained time period, and then you're doomed anyway, cause the minimal time-period that a linux 2.2 kernel can give you, on anything but an ALPHA, is 10 milli-seconds - and not even that, in various situations). > I use an empty select() to do time delays. I'm hoping to use a more useful > form of select() in the future to eliminate any I/O delays (and the rest are > debug trace visual aids). > > I tried to verify that pausing using an empty select() doesn't get > interfered with by SIGALRM. It apparently is OK, but "nobody said > otherwise" isn't the sort of proof I like. So the first question is > whether these two functions play nice with each other. actually, if you select() and there's a SIGALRM received, your select might be aborted with error -1, and errno set to 'EINTR'. your code should always be prepared to handle EINTR. see the man page for select(), and look at the error codes section in particular. the same is true for many other system calls. --guy -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
