Signal_dispatcher & base-hw

[Norman Feske]

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/a6acab6d0d5e907b63176aca9cd2ce496d6b9fea

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

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