FIFO handler instead of pooling

I want to use a FIFO between two processes but wouldn't like doing pooling in while loop and waste some CPU cycles (this is intended to be used for an embedded app.)

I know that RTLinux as well as RTAI can provide that sort of mecanism but there's no timing constraint in my project...

Is there any way to do this in user space ?

fcntl + signal processing = prossible solution for the "read" end of the FIFO ?

Just what do you want to do? Wait for a byte to become available? Test and come back so you can do something else in the meantime? What?

Why not use message queues and semaphores?

man ipc, then look at all of the "see also" functions.

Well, it's just a matter of calling let's say function "myhandler" when data is received on the FIFO. I don't want to put the read end in an infinite loop... which is not optimal.

I'm pretty sure I can do something using the signal() function but would be pleased having some tips about that. I'm sure I'm not the first who ever used a FIFO... someone probably went over the same thing.

I'm sure I'm not the first who ever used a FIFO... someone probably went over the same thing.

I have done exactly that - by using message queues to host the data and semaphores to control the blocking... :-)

I can understand your idea. Would you have a code snippet to share to make things even more clear ?

rstewart, the problem with using message queues and semaphores is that if your program dies, the message queues and semaphores hang around, even when there's no longer any process using them. The system only allows so many message queues and semaphores globally, so a message queue leak or semaphore leak can cause problems.

pierre-luc, if you're contemplating using signals, you probably already know that you should minimize what you do inside a signal handler. It's safest to use the signal handler to set a flag, and then check that flag periodically in your code.

But if you're going to check periodically in your code, why not just forget the signal stuff and use select()? It lets you test whether input is available on a given file descriptor (or whether a given file descriptor can accept output without waiting).

man select

Hope this helps.

I ended up with this solution:

Process A writes its pid in /var/run/myprogram/pid
Process A creates shared memory
Process A sigaction() on SIGUSR1
Process B reads /var/run/myprogram/pid
Process B attaches to shared memory
Process B writes to memory
Process B send SIGUSR1 to process A
Process A calls handler
...

thanks to pireau on #linux-quebec for the help.

I recently was facing the same problem, perhaps worse because I needed to do it with BASH. I wanted to run a process that would respond to events and re-respond as well as trigger other events. I wound up using signals and traps to get what I needed:

#!/bin/bash
# /usr/bin/Xusb-hotmount

MY_PID=$$

trap_int() {
sleep .5
usbwatch &> /dev/null

}

while [ -d /proc/$MY_PID ] ; do
trap trap_int 2
# note that leaving out this initial start of the program means that the loop waits for
# an INT signal before starting the program above.
usbwatch &> /dev/null
done

The above code starts/restarts the usbwatch program. It gets interrupted (INT) periodically by other processes and needs to be re-started so that its' runtime configuration or status is updated.

As noted in the comments above, if you comment out the intial start of usbwatch then the first INT only gets you to the start of the function. A second INT will then start the usbwatch program. Sending an INT or KILL to the above program leaves usbwatch running, so to both programs, the program usbwatch gets sent an INT and then the above program gets a KILL.

There are some pretty interesting possibilities if you just start experimenting.