Hi, All.
We were investigating problem of sending big amount of data via network in Genode on Fiasco.OC. And we have found out some significant bug of the Genode Signal service implementation and we also could provide the simple stable solution. As know Packet_stream_rx and Packet_stream_tx implementations (os/include/packet_stream_*) are based on a Signal service (signal.lib) and use RPC submit(Signal_context_capability context) of Genode::Signal_session (base/include/signla_session/signal_session.h). And this submit RPC is invoked all the time while RX – TX packet transferring (as the packet acknowledge). So the problem is that the submit is RPC and according to RPC implementation all parameters, which are capabilities, are passed by special way know as capability marshalling/unmarshalling (base-foc/include/base/ipc.h). And while capability unmarshalling the new l4_cap_sel is allocated and capabilities are mapped once again all the time. In the limit all capability table of the l4 task will be filled completely; especially while intensive packet transferring. And it damages the Genode Core foremost and provides other troubles. As we investigated the decision of using the capability in a sense of signal context is redundant. Signal_session_component::submit uses Siganl_context_capability only for searching it in the context entrypoint (base/src/core/signal_session_component.cc). But the same effect could be achieved by searching signal context by a badge(local_name()) and then there would not be necessity of capability unmarshalling. The decision is quote simple to change the Signal_context_capability typedef from Capability<Signal_context> to simple int or long type (base/include/signla_session/signal_session.h) and then to fix all errors generated by compiler. So we think that this problem of Signal service is significant and has to be fixed as quick as possible. But of course we'll glad to hear any your remarks about the decision to use the capability is a sense of Signal_context.
Best, Ivan Bludov.