Hi, On Sat, Jun 06, 2009 at 09:58:24AM +0200, Martin Preuss wrote: > It can't have an infinite loop: It runs in a single thread and needs > to do some cleanup from time to time (e.g. releasing readers and cards > after some timeout etc).
Actually, it can, if I understand your problem correctly. You are saying that a forked child will eventually die and needs to be cleaned up? If you don't ignore SIGCHLD, but handle it with an empty handler, then this handler is called when a child dies. Even if the handler doesn't actually do anything, it still aborts a select call with EINTR (interrupted system call). Also, if there is a timeout when things actually need to be done is not a problem. It's fine to have a non-infinite timeout if there is a real event scheduled. But "check if there are events" should not be a reason to wake up. If there is an event, you should make sure that you are notified without polling. In most cases, this is possible. To be clear, here's an example timeline: ... - wait with infinite timeout - handle some event - wait with 10 second timeout - timeout reached, clean up after event - wait with infinite timeout ... The use case I'm thinking of is that the program is not used (at all, or for a significant time), but running anyway. This can be useful. In case of this daemon, for example, it makes sense to always have it running even if it is only used once a week. There are two things which are important in that case: 1. The cpu time consumed must be minimal. 2. The program must stay in swap if it's put there. Of course, point 2 implies point 1, because a program is retrieved from swap when it uses any cpu time at all. You're saying it's not possible to have a real infinite loop. Is there a reason (other than dying child processes) for this? > Please note that compared to other chipcard daemons libchipcard4 is probably > more power conserving since it doesn't open devices as long as they aren't > used (which allows USB autosuspend to kick in). That sounds good! Again, I'm not saying it's a bad program. I'm just pointing at something which can be improved. ;-) > BTW: How do you determine how much CPU time the daemon is using? You > are aware that the output of "top" is not as reliable a source as one > might think? I did indeed use top, but it was not relevant to me if it was accurate. My main concern is that it is not 0, meaning the program keeps itself in physical memory permanently. That is bad for a program which may be unused for days. > If you don't use the service of the chipcard daemon it mainly sits on > a select() call and waits. If hardware polling is enabled then it > wakes up every 1-2 seconds and checks for new hardware. If not it > sleeps about 10s and then shortly looks for due chores. If there are > none the daemon immediately falls back to sleep. Right. And this is much better than running a lot, but it still means it can never be in swap for long. If that can be fixed, it would be an improvement. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html
signature.asc
Description: Digital signature
