[reSIProcate] Dynamic binding to interfaces and ports
Alan Hawrylyshen
alan at jasomi.com
Fri Oct 28 08:32:54 CDT 2005
On 27-Oct-05, at 21:07 , Matthias Moetje - TERASENS GmbH wrote:
> Alan,
>
>
>> Sounds like a leak recipe. I think we can get away with reference
>> counting the transports.
>>
>
> Why do you think that this is a leak recipe? I assume the current
> transport handling does not expose any leaks. So regardless of a
> transport's state (enabled or disabled) it should be cleaned up
> some time. A transport would only be disabled in case of a
> configuration change. Even if there are 10 configuration changes,
> would it be a big problem to have 10 inactive transport objects?
> A case of thousands or even millions of config changes is not
> realistic.
>
> Our application could perfectly live with that. Implementation of
> the disabled state is independent of the reference counting approach.
> If someone wants to use the disabling of transports _AND_ is
> concerned of a leak he might add reference counting afterwards....
I'm just thinking about LONG term processes (proxies, etc) that might
want
to reconfigure without a restart. It would be best if the design
contemplated
an interface that could support clean (delayed) removal of transports.
Otherwise I think we are on the same page.
Cheers,
Alan
More information about the resiprocate-devel
mailing list