Hello Yuqing Wang,
I used launchpad to start a hello_client and hello_server.I closed hello_server and expected the call from hello_client could cause an ipc error ,because the target is not exist .
I cannot give you details about the Fiasco.OC-specific part of your question but I welcome the discussion about IPC errors in general.
Recently, I came to the realization that we should remove the notion of IPC errors from the Genode API. Why is that? In general, a client that calls a server ultimately has to accept that the call may never return. Such a call is similar to calling into any piece of unknown code such as a 3rd-party library. For example, the call may never return because the server has entered an infinite loop. For the client, it make no difference whether the server behaves that way or the server does not exist at all.
In your case, the parent intentionally killed the server process. If the client receives an IPC error, it gains the bit of knowledge that the server does not exist anymore. But maybe the parent wants to hide the fact? When reflecting such a condition in the form of an error code, the parent has no means to hide this information from the client.
Currently, there exists the 'Ipc_error' exception but I cannot come up with a use case where the knowledge about an IPC error actually helps the client. In current Genode components, this condition remains unhandled anyway and lets the client process abort. In the case where a server disappears (note that this condition is always mandated by the common parent of both client and server), it makes hardly any difference whether the client process aborts or simply gets stuck. The parent wanted to get its child into trouble - so be it.
Finally, the conditions for IPC errors are not consistent across the Genode base platforms. An IPC error is always some exceptional condition but its root cause varies. For example, on Linux, an IPC error occurs when the client cannot create a socket pair (e.g., due to a resource limit). On OKL4, an IPC error is merely raised during a failed send phase of an IPC. On NOVA, IPC errors are never raised in the platform-specific code. Because of these differences, platform-agnostic code generally cannot draw a meaningful conclusion about handling such an IPC error.
It sounds like you have a valid use case for responding to IPC errors. If yes, I would very much appreciate to learn about it.
Cheers Norman