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). 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 do_something(). 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 elevation. If validation fails, how is that handled? This is relevant for debugging buggy apps. > > 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
