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

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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Genode-main mailing list
Genode-main@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main