[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: the MICO/CORBA issue.
From:       Jo Dillon <emily () thelonious ! new ! ox ! ac ! uk>
Date:       1999-09-15 10:43:09
[Download RAW message or body]

Matthias Elter (me@main-echo.net) spake thusly:
> A buggy component running in a seperate process can easily take down the main
> app, too. You can't try/catch every CORBA call.

  Perhaps we should make it /possible/ to load the component in a separate
address space for applications that want to do this and can handle it.
But shared libraries should be the norm.
  Another interesting point - could we get rid of the stubs this way?
That is, when we compile a component we generate two libraries.
Library A contains the basic code for a local component, which mico
can presumably call directly without messing about with stubs. Library B
contains the networking stubs/ If you're loading a shared library,
you just pull in library A. If you're making a container to hold an object
talking to a non-local object, you pull in Library B too. This way
you don't need to load the stub code if you're not using it, which will
get rid of some of the accusations of bloat. I know that modern Unix
is pretty intelligent about pulling in code, but I suspect that at the moment
networking stub code is still being pulled in when it isn't needed.
And we certainly could do with getting down the CORBA memory overhead.
Of course, this only works if the local-component code can survive without
the stubs...
  Another, rather more blue-sky thought - has anyone on the Mico team
looked at libffi? (http://sourceware.cygnus.com/libffi/). It seems to me
that if you knew enough about the compiler - the format of its vtbls,
how it handles multiple inheritance thunking, its name mangling and so forth -
you could use this library to do away with server-side stubs altogether
and do all calls dynamically.

-- 

	Jo

[prev in list] [next in list] [prev in thread] [next in thread]