uClinux Interrupt issues

What I described has nothing to do with polling. In fact the name of the epoll() function is misleading (See "Linux Device Drivers" by Rubini et al).

- The driver can unblock read() immediately after the interrupt was handled

- The driver can unblock select() immediately after the interrupt was handled. Now the user program will immediately execute the appropriate code unless it still in some other path and did not reach the select statement

- similar stuff is happening with epoll(). Here the alternatives don't need to be scanned but are addressed directly.

- If a multithreaded program dedicates one thread to waiting on the event to happen, it can do the blocking read() and thus start immediately after the driver handled the interrupt. If this thread has a higher (realtime-) priority than other threads it will preempt all other threads of the application and do it's work at once (unless the Kernel schedules some even higher priority tasks).

-Michael