Hello Genodians, I'm hoping someone can help or point me to a good reference for the error that pops up occasionally saying "attempt to handle the same signal context twice (nested)". This happens within some Sculpt components (decorator, depot_query), but also happens in this USB wifi driver I'm trying to make. Mostly I want to understand it - my long explanation is below.
My basic understanding is Genode gets upset when waiting for a signal within another signal handler. However, the "natural" way I would like this driver to behave is to be signal driven - all code is responding to some signal or other. However, sometimes one needs to do synchronous IO operations. If it is truly forbidden ever to wait within a signal handler, I considered a few options, but found all to be non-ideal. 1) Use stub signal handlers to insert elements into a work queue and drive everything from an event loop. This seems like reinventing the signal mechanism, but might be what's required. 2) Build state machines to break up synchronous IO operations with no waiting at all. This makes simple-looking operations complicated and increases debugging complexity. 3) Busy-wait for synchronous operations. Probably a big performance penalty, and obviously wasteful.
So I proceeded, because I do notice that sometimes it is OK to wait within a handler (i.e. the warning does not occur). But I still get the warning other times, and I can't quite figure out when or why it happens. Initially, I thought that if I separated things out, so that, say, Signal_context A waits, but can only receive signals for Signal_context B or C, it would be OK. Now, I am not totally sure I've actually achieved this, but I think that I have, and I've become suspicious that I don't really understand the "rules." So, is there a way to understand when one can wait safely wait within a signal handler? Is it really as simple as "Signal A cannot be generated while waiting if a handler for A is on the stack?" Does the App vs IO signal distinction come into play (I have both). Also, is there a way to get a Genode app to output a stack trace - I can patch that warning mesage to output a stack trace and at least see what actually happened?
Thanks as always to the Genode community for sharing your knowledge with me.
Best regards, Colin