Am 11.12.2015 um 12:24 schrieb Anton Ivanov: > On 11/12/15 08:16, Richard Weinberger wrote: >> Am 11.12.2015 um 07:58 schrieb Anton Ivanov: >>>>> 2. I cannot catch what is wrong with the current code in signal.c. When >>>>> I read it, it should not produce re-entrancy. But it does. >>>> Sorry for the delay. Until now I did not find the time to dig into that. >>>> Did you find the offending code in signal.c? >>> Yes. >>> >>> Unblock signals is logically incorrect - it will re-trigger an >>> interrupts even if there is an interrupt in flight whose processing has >>> not been finished. >>> >>> I tried several approaches both with the original poll() controller and >>> with my epoll() based version, some show promise. >>> >>> I had to put it aside until next Friday as I have some stuff due at work >>> so I cannot spare time to work on it until then. Once I get that out of >>> the way I should be able to spare it a day or two which should be enough >>> to finish it. >>> >>> Ditto for the UBD improvements. >> One thing we have to consider is that's legit to have SIGIO nested. > > Correct. That is considered :) > > Both when looking at poll() and epoll() > > However, it is not legit to have sigio on a specific fd nested. That is > mostly safe for the poll() version, but will need to be accounted for in any > surgery on the irq controller.
So, the current code is fine unless you switch to epoll()? Is it because you use epoll() in edge-triggered mode? Thanks, //richard ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
