> If you don't do a blocking call, you will never leave CPU and thus the
> machine will not do anything else. Even kernel threads won't run - they
> are high priority normal proceses, not realtime.
No, what i mean is do not block in the kernel, do a sleep()
in the application.
for( buff_index = i = 0; i < xfer_count; i++, buff_index =
(buff_index+1)%MAX_BUFFERS ) {
sleep(1000);
read( buff_fd, (mbuff +buff_index*BUFF_SIZE), BUFF_SIZE );
}
The above code, ( u can see the details for my previous mails )
sleeps till driver wakes it up through kill_fasync() which is there is an
interrupt handler.
Usually u get an interrupt after the devices xfers the data through DMA.
So CPU time is given to other processes during that sleep.
The sequence would be :
driver uses ioctls to start xfer ( which is non blocking )
Application sleeps during that time giving cpu to other processes.
dma does the actual xfer and inform driver through interrupt.
irq_handler informs application through fasync and sleep function
immediately returns even before timeout ( refer man page for sleep ).
So the switching time is minimal and also this guarantees contineous
streaming
of the video.
This i hv tested for a bandwidth of 20 Mbits/sec.
I did that first with a blocking call, which resulted in frames being
displayed with a delay ( due to the time between ur blocking call returning,
and application refilling the buffer ).
-nagaraj.
\(*_*)/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
