Hello,
this fix prevents possible deadlocks in rt_intr_delete() vs. ISR
handlers that I have mentioned earlier.
--
Best regards,
Dmitry Adamushko
native-intr.c-delete-rework.patch
Description: Binary data
posix-intr.c-delete-rework.patch
Description: Binary data
Dmitry Adamushko wrote:
Hello,
this fix prevents possible deadlocks in rt_intr_delete() vs. ISR
handlers that I have mentioned earlier.
Applied, thanks.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Dmitry Adamushko wrote:
Hi,
I haven't had access to my laptop during this week so the patches
follow only now.
Merged, thanks.
Yet another issue remains that may lead to a deadlock under some circumstances:
- rt_intr_delete() calls xnintr_detach() while holding the nklock.
-
Another approach would be to introduce a service like
xnintr_synchronize() and enfource the upper interfaces (e.g. skins) to
make use of it in their _delete() methods.
That would be useful too for solving the concurrent ISR while deleting
issue, but would not enforce single deletion in
Hi,
I haven't had access to my laptop during this week so the patches
follow only now.
Yet another issue remains that may lead to a deadlock under some circumstances:
- rt_intr_delete() calls xnintr_detach() while holding the nklock.
- xnintr_detach() (with CONFIG_SMP) spins in
Dmitry Adamushko wrote:
Hi,
the following question/suggestion :
it could be good to eliminate the use of rthal_critical_enter/exit()
from rthal_irq_request() if it's not
strictly necessary.
the proposal :
int rthal_irq_request (unsigned irq,
rthal_irq_handler_t
