Paul Koning wrote:
>
> I was looking at the rtl_fifo.c code and something struck me... If
> you write to /dev/rtf<n>, you can specify any length you like,
> including one longer than the fifo buffer size. Fine, the user
> process stalls in mid-write until the real time thread makes more
> room, then continues, repeating until the write count has been
> satisfied.
>
> The question: it seems likely that a real time thread will be using
> the rtf handler mechanism to trigger reading from the fifo. Normally
> that's not a problem, but in the case I mentioned the handler isn't
> invoked until the write is done. That's consistent... but it means
> that you may have a deadlock.
>
> Even though it's slightly inconsistent, it seems appropriate for this
> situation to call the handler when the user process is about to be
> stalled due to lack of room.
>
>
Hi Paul,
If you go to http://www.zentropix.com/downloads.html you can find
rtai_rtl_fifos.tgz this is an updated fifos package that includes lot of
additional IPC's for user/rt space and works for RTL and RTAI. In your
particular case, you can use the following call in rt space (or user
space):
rtf_sem_trywait(fifo_no)
This returns true if you can read/write to the fifo, hence gives a
non-blocking check on the fifo.
Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
