Signal_dispatcher & base-hw

Norman Feske norman.feske at ...1...
Wed Jan 30 12:29:01 CET 2013

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:

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.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list