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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
