Re: [Libreoffice] UNO Object Life Cycle question

Le 05/01/2012 18:52, Tomas Hlavaty a écrit :
> Hi all,
>
> I'm implementing
> <http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#Object_Life_Cycle>
> and can't make much sense of it.  It seems to me that the spec is
> contradictory:
>
>    ...  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
http://www.execute-info.com/RemoteOfficeDemo.zip

with my tests, there's a release for each tuple like for this 
XInputStream after a LoadComponentFromURL('private:stream'...) :

releasing 
com.sun.star.io.XStream:26367c8;uno[0];e0c;a57318a2d6e42fbaa3badc46a60b671
releasing 
com.sun.star.io.XSeekable:26367c8;uno[0];e0c;a57318a2d6e42fbaa3badc46a60b671
releasing 
com.sun.star.io.XInputStream:26367c8;uno[0];e0c;a57318a2d6e42fbaa3badc46a60b671
releasing 
com.sun.star.uno.XInterface:26367c8;uno[0];e0c;a57318a2d6e42fbaa3badc46a60b671


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 
are released.

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.

Paul TOTH
> 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,
>
> Tomas
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice