Re: ActivationContext and shlib servers

[Dietmar Maurer <dietmar ximian com>]

Maciej Stachowiak wrote:

> Dietmar Maurer <dietmar ximian com> writes:
>
> > Why does oaf always activate a new server if the code is
> > in a shared library (even if I register my object with
> > oaf_active_server_register() )
> >
> > Maybe the error is in ac_do_activation(), which does not check
> > if the server is already active (for server_type == "shlib").
> >
>
> The technical reason is that an shlib server is only active for a
> given process. Thus, it really makes no sense to register it with oafd
> as things stand, since registration is a global thing, not a
> per-process thing.

Oh, that makes sense ;-)

> Fixing this is possible but would require tricky hackery in both oafd
> and liboaf (you'd need to be able to register the shlib server per
> process, and liboaf would have to query oafd for shlibs servers
> registered for - or else oaf_active_server_register would have to
> register shlib servers in a table inside the process instead of
> talking to oafd).

I think your second approach is quite easy to implement.

> I actually suspect the current behavior may be intentional (shlib
> servers are sort of implicitly factories), but only Elliot knows for
> sure. It appears to be the same as the goad behavior from what I can
> tell.
>
> Can you please explain to me why you need this behavior, and if you
> are still convinced the current behavior is wrong.

We have a new object tracking system in bonobo, which counts the
objects activated from within a shared library. This enables us to
unload the shared library if all objects (in the library) are
deactivated.
The code assumes that oaf only activates necessary factories. To activate

a new factory every time is simply useless (I can see no reason
to do that).

I see two solutions:

1.) oaf_active_server_register would have to register shlib servers
in a table inside the process instead of talking to oafd

2.) I can change the bonobo code to deal with multiple factories.

I would prefer solution 1.

- Dietmar