If i didn't misunderstood the function of 'Signal_dispatcher' it should be provided through a separate header. This is because 'base-hw' implements the basics of 'base/signal.h' (Signal, Signal_receiver, Signal_context, Signal_transmitter) by itself, to optimize the code via specific kernel-mechanisms. But there seems to be no need to add a specific implementation of 'Signal_dispatcher' because it only .
Am i right?
Hi Martin,
If i didn't misunderstood the function of 'Signal_dispatcher' it should be provided through a separate header. This is because 'base-hw' implements the basics of 'base/signal.h' (Signal, Signal_receiver, Signal_context, Signal_transmitter) by itself, to optimize the code via specific kernel-mechanisms. But there seems to be no need to add a specific implementation of 'Signal_dispatcher' because it only .
Am i right?
I see the problem in a slightly different light. In principle, you are right that the new 'Signal_dispatcher' could be placed in a different header file. So you could fork the remainder of 'signal.h' without the need to duplicate this piece of code.
However, I think, we could also try another solution. How about attempting to alleviate the fork of 'signal.h' at all? Right now, 'base-hw' maintains a custom version of this file. Recently, the generic version underwent quite important changes such as the addition of the 'Signal_dispatcher' interface. But more importantly, we changed the semantics of the 'Signal' object to fix a subtle race condition. See here for the corresponding commit:
https://github.com/genodelabs/genode/commit/a6acab6d0d5e907b63176aca9cd2ce49...
In short, the commit turns the 'Signal' object into a some kind of shared pointer that counts the references to its associated context. As long as a signal is in flight (i.e., a signal is currently handled), the destruction of its associated context gets delayed. Prior this patch, a signal context could be destroyed while the signal handling for this particular context was still in progress. This problem triggered only on one kernel with one specific Noux-related test case. But the issue principally exists on all platforms. So we had to fix this potential race condition.
Consequently, the base-hw version of 'signal.h' should be revisited to apply the same fix. When doing so, we could try to merge both versions so that base-hw would use the generic 'signal.h' in the end. I don't know whether this is feasible or not but it is certainly worth a try.
Cheers Norman