However, and this is crucial, even with a "dual-mode" kernel like QXK, event-driven Active Objects should never block internally. Blocking must be confined to the traditional threads only (QXThreads in QXK). Yeah, I should have clarified that with QXK, you just stick the blocking 3rd party code into a thread with an interface to handle events and call the appropriate blocking functions only from that thread.
Miro, correct me if I'm wrong but one way to mix blocking and non-blocking "safely" seems to be to use the QXK kernel instead of QV or QK.
I couldn't figure out how to make it work but in the end, it didn't seem like a huge impediment so I decided the effort wasn't worth it. That said, it did seem like a nice idea but if it's breaking safety stuff, I won't miss it.
You can just run QP with the posix port on any linux. I do this in yocto, ubuntu, and RHEL.
But now you're going to have to create some sort of way to keep state in your ISR to know that you've processed the right number of events or some other flag to know when you can unpause. You're just creating a state machine when you already have one. This seems wrong.
Is the system working correctly with deferral queues? This seems like the correct solution assuming you're not posting so many events that you run out of room.
I don't understand how this feature would even work. If you pause the AO, how do you unpause it? You can't send an event to it since it's paused and not handling any events. I think your approach with deferral queues is the correct one, assuming you're not posting so many events that your system simply can't keep up with it.
Yeah, the explanation makes sense. I actually welcome the change, especially if I get safety certs as part of the bargain. So, this is one part of your question/problem. I sincerely apologize, if this new error handling policy is not completely backward-compatible, but I don't see a clear way around it. Yeah, totally understandable. I was just hoping for a quick way to scan my code to fix any potential mines left behind from the previous version. The startup sequence diagram helps. Any other resources...