One of functionalities I miss the most from "small embedded" in Embedded Linux is the interrupts. A signal appears on a specific pin, or other interrupt source is triggered and whatever was done inside the CPU gets interrupted, and my function of interrupt handler is launched. In Linux everything is buffered, if something happens the system just goes about its own course and when (at last) given thread is brought to foreground, its wait-state expecting the external source ends, and its handler starts.
The closest thing I know are the signals, which can trigger a handler interrupting normal flow of the thread, but still, the handler will not pick up the signal until the kernel brings the thread into foreground, which may be many milliseconds after the signal happened - and triggering the signals isn't as robust either; I need an app or a kernel module to send a signal, I can't just trivially attach it to a GPIO pin.
How could I achieve a functionality similar to hardware interrupts within Linux userspace software - have a specific function launched or specific thread brought to foreground immediately after an externally sourced condition is triggered, without waiting for the process queue to bring my thread to foreground?
If you feel this question is too broad, let's narrow it to a specific example: a Raspberry Pi board receives a signal on one of its GPIO pins (not necessarily arbitrary; if only some pins can do that, that's okay.) I want my userspace application to react to this event within least time possible, be it bringing it out of wait state, launching a handler function or any equivalent mechanism, but above all not waiting for the task queue to cycle through all pending processes before the handler is brought to foreground, but trigger it ASAP. (and specifically, when there is no signal, not leaving the system locked forever with the handler process occupying 100% CPU time polling the input and never yielding to the OS.) Is there such a mechanism?