I know the evils associated with using rtprio, but I have a real real-time application that needs to service data very quickly when it is needed from a piece of hardware. This daemon reads from a special device. The driver's read handler puts it to sleep, and wakes it back up when an interrupt comes in. Other processes communicate with this daemon using fifo's. (They send it packetized commands, and every once in a while through the loop it checks the fifo for data). According to my Stevens book here, fifo and pipe writes are guaranteed to be atomic, as long as the write is less than PIPE_BUF. (which is 512 bytes here). Unless I'm using rtprio, this is true. Apparently I'm somehow stealing execution away from the child processes during their write() in the middle of it. Occasionally, when I should be reading 192 bytes in from the fifo, i'll do one read of 89 bytes, and another of 103. This wasn't hard to code around, I just kept a buffer, and only processed it when I had a complete packet. However, about once every 6-8 hours, the daemon will get stuck in 'sbwait', and no amount of kicking it will make it wake back up. If I don't use rtprio, this doesn't happen, but the process becomes too slow to work. Has anyone run into this before, or does anyone have any suggestions on how I might fix this? I may try SYSV style message queues next, if I"m not able to fix the fifo problem. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
