[Dev] First measurement of the SAPI overhead
jose.bollo at open.eurogiciel.org
Wed Jul 2 11:50:13 GMT 2014
On mar, 2014-07-01 at 15:26 +0200, Patrick Ohly wrote:
> On Fri, 2014-06-27 at 15:14 +0200, José Bollo wrote:
> > On ven, 2014-06-27 at 14:09 +0200, Patrick Ohly wrote:
> > > More interesting for the discussion is something else: how much slower
> > > (in percent) will SAPI be compared to CAPI? For that, one needs to look
> > > at which method calls will be wrapped by SAPI - all of the CAPI methods
> > > or only some?
> > No.
> I assume that this is a "no, all of the CAPI methods get wrapped" (which
> you confirmed below).
You are right. It may change in the futur but it is the current case of
> This leads to another question: suppose we have a "some_struct
> *some_struct_new()" and a second method using that pointer, for example
> as in "void do_something(some_struct *p)".
> At the moment, a misbehaving app process will crash or at least only
> corrupt its own memory if it passes an invalid pointer to
> What kind of checks are done by the SAPI proxy server when it receives
> the parameter for do_something()? Does it validate the pointer or does
> it fully trust the app to behave?
> Remember, the proxy runs with higher privileges than the app talking to
> it. Using data from the app without checking is insecure; I bet one
> could easily crash the proxy daemon or worse, use this for privilege
> If validation fails, how is that handled? This is relevant for debugging
> buggy apps.
This is a really serious topic that you are pointing here. Using direct
address is bad. Using handles is also bad for the same reasons: it could
be a lying handle too. So the only answer is checking and accept the
price to pay for it.
However, the server process of SAPI forks for each incoming client.
Thus, a client would only crash its server instance not the instances of
the other clients. The main reason for doing a fork is that the
encapsulated core APIs are free to define static data/state that must
not be shared between instances.
> > > As Carsten pointed out in his email from June 16th, if CAPI has method
> > > calls which execute locally in the process at the moment and SAPI
> > > replaces that with remote procedure calls, then performance will be
> > > considerably slower. If these methods get called often, then this will
> > > matter.
> > But this have issues: where is the context? In the client or in the
> > server? That might be a nightmare. Thus, for first, we are studying the
> > worst case, when all call are passed to the server.
> Handling context in the server is also tricky.
More information about the Dev