[Libreoffice] UNO Object Life Cycle question
execute.sarl at gmail.com
Thu Jan 5 08:23:39 PST 2012
Le 05/01/2012 18:52, Tomas Hlavaty a écrit :
> Hi all,
> I'm implementing
> and can't make much sense of it. It seems to me that the spec is
> ... unless it considers as bridged in any tuple<o, t'>, where t' is
> a subtype of t (including t itself). If the same tuple appears
> multiple times in the data of a message, the corresponding reference
> count is incremented multiple times.
> The optimization rule (to not increment the reference count for<o, t>
> when<o, t> itself or some subtype tuple<o, t'> is considered as
> bridged in) is broken...
> The last quoted paragraph:
> to not increment the reference count for<o, t> when<o, t> itself or
> some subtype tuple<o, t'> is considered as bridged in
> doesn't sound like reference counting. If the client fetches XInterface
> first, then the reference count can only ever be maximum 1. It somehow
> seems very dependent on what types the client fetches in what order.
> Also this rule contradicts the sentense:
> If the same tuple appears multiple times in the data of a message, the
> corresponding reference count is incremented multiple times.
> By the exceptional rule, the tuple's refcount should not be incremented.
> Is the exceptional rule really meant to say "including t itself"? Or
> does the part "in the data of a message" make the exceptional rule
> somehow invalid in the context of one message?
> Is this spec still valid?
> I implemented the algorithm according to my understanding of the above
> spec reducing memory leaks by 1/2 but I still get many leaks. If I'm
> strict and ignore the broken optimization rule, I get LO crashing after
> some time, likely because of double release. I'm still missing
> something to get refcounting exactly the way LO does it.
> Why is the reference counting algorithm dependent on the casted type in
> the first place? Shouldn't the reference count be interesting only in
> connection with oid and not<oid,type>?
> UNO is a distributed protocol. The links should be considered
> unreliable. Is there a mechanism that when a link between the server
> and client bridge breaks, the server releases the resources properly, or
> do we get/expect memory leaks?
My own experience with this protocol is with a Delphi client
with my tests, there's a release for each tuple like for this
XInputStream after a LoadComponentFromURL('private:stream'...) :
I've notice that an unreleased objet persist after disconnection, if you
start a new session with the same threadID the server raise an exception
when you try to send a previously used OID. So I don't know when they
And on an other hand, I don't know how you can reconnect to the same
thread after a client crash ! AFAIK all the objects should be just
droped down on disconnection, but they're not.
> Also, it is not exactly clear at which point in time the release message
> should be sent. One such point in time could be when the client is
> finished with the session. At that point, the client needs to send at
> least as many release messages as the number of all the incremented
> refcounts it noticed according to this algorithm. That is potentially
> many messages, slowing down the session considerably. Is there a way to
> simply end the session and declare all references not used anymore in
> one go/message without causing leaks in the server?
> Thank you,
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
More information about the LibreOffice