Ok, aside from the below-mentioned bug involving user_pairs, my testing
reveals that in all seriousness, half the time rtf's block indefinitely on
select() system calls (ones that have struct timeval == NULL) even though
I CAN PROVE NEW DATA IS BEING GENERATED! (Sorry for the caps! :) ).
Can someone who knows more about the code double-check this, if they have
time? It isn't critical, as I can do 'polling selects', but it would be
nice to do really elegant fully blocking selects...
-Calin
On Fri, 16 Nov 2001, Calin A. Culianu wrote:
>
> OH MY GOD! Excellent catch!! I sincerely hope the fsmlabs team accepts
> your fix for inclusion into future versions of rtf.
>
> What is a user pair? Is it combining 2 fifo's from the kernel into 1 user
> fifo? What is the point of this?
>
>
>
>
> On Fri, 16 Nov 2001, John_Jacques wrote:
>
> > I just fixed a similiar problem in rtl_fifo.c that caused linux
> > applications to stay blocked after an RTLinux module called rtf_put.
> > Note the following from the end of rtf_put in rtl_fifo.c
> >
> > if (RTF_USER_OPEN(minor)) {
> > fifo_wake_sleepers(minor);
> > }
> >
> > If you make a user pair only one minor number is open
> > (RTF_USER_OPEN(minor) != 0). Consider the following sequence of events:
> >
> > /* In init_module( ) */
> > rtf_create( 10, size );
> > rtf_create( 11, size );
> > rtf_make_user_pair( 10, 11 );
> >
> > /* Linux application */
> > file_descriptor = open( "/dev/rtf10", O_RDWR );
> > read( file_descriptor, buffer, size );
> >
> > At this point RTF_USER_OPEN( 10 ) equals 2, RTF_USER_OPEN( 11 ) equals 0
> > and the Linux application is blocked on the read.
> >
> > /* RTLinux module */
> > rtf_put( 11, buffer, size );
> >
> > The code, noted above, in rtl_fifo.c does not wake up the linux
> > application!
> > My fix is as follows:
> >
> > if( RTF_USER_OPEN( minor ) ||
> > ( ( 0 != RTF_BI( minor ) ) &&
> > RTF_USER_OPEN( minor + RTF_BI( minor ) ) ) ) {
> > fifo_wake_sleepers(minor - (RTF_BI(minor) < 0));
> > }
> >
> > "Calin A. Culianu" wrote:
> > >
> > > What is supposed to happen when a user-process does the following?
> > >
> > > int n_ready;
> > > fd_set rfds;
> > >
> > > /* assume fd is an already-opened /dev/rtf */
> > > ioctl(fd, FIONREAD, &n_ready);
> > >
> > > if (n_ready == 0) {
> > >
> > > FD_ZERO(&rfds);
> > > FD_SET(fd, &rfds);
> > > select (fd+1, &rfds, NULL, NULL, NULL); /* block indefinitely waiting
> > > for new stuff on fd */
> > >
> > > }
> > >
> > > Basically the above code snippet blocks forever whenever the ioctl
> > > detects 0 bytes ready for reading.. even though I *know* my real-time thread
> > > is generating more data on the fifo...
> > >
> > > Is this a bug/lacking feature of /dev/rtf or a simple stupid thing i am
> > > overlooking? I guess I can open up the rtl_fifo.c file and have a gander
> > > at it myself.... but maybe one of you can save me the trouble.. thanks!
> > >
> > > And I know.. I could just open the fifo with blocking reads, but I
> > > wanted to see if I could selectively block and not block on demand using
> > > select()...
> > >
> > > -Calin
> > >
> > > -- [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/
>
> -- [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/
>
-- [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/
