Xojo Conferences
XDCMay2019MiamiUSA

Unlocking or not? (Real Studio Plugins Mailinglist archive)

Back to the thread list
Next thread: Debugging plugins, hellooo????


macosx and unix paths   -   GOLD
  Unlocking or not?   -   Alfred Van Hoek
   Re: Unlocking or not?   -   Jonathan Johnson
   Re: Unlocking or not?   -   Christian Schmitz
   Re: Unlocking or not?   -   Alfred Van Hoek
   Re: Unlocking or not?   -   Jonathan Johnson

Unlocking or not?
Date: 28.06.07 01:33 (Wed, 27 Jun 2007 20:33:35 -0400)
From: Alfred Van Hoek
Getting confused. If an event or Interface method is returning or
byreffing an object, do you really need to unlock it, or not? If we
don't, we leak our retInstance object ("myClass", see below). (Unless
the dictionary class containing myClass instances is leaking)
Example:

REALmethodDefinition InterfaceMethods[] = {
/*0*/ { (REALproc)nil, REALnoImplementation, "GetStringIdentifier
(utf8name As String) As myClass"},
};

REALinterfaceDefinition Interface = {
kCurrentREALControlVersion, // just pass
kCurrentREALControlVersion
"StringIdentifier", // interface name
InterfaceMethods, // list of methods the interface requires
sizeof(InterfaceMethods) / sizeof(REALmethodDefinition) // how many
methods there are
};

typedef void* APIIdentifier;

//The lib callback
APIIdentifier API_GetStringIdentifier(const char *name)
{
APIIdentifier api = NULL;
REALstring theName = REALBuildString(name, strlen(name));
if (myInstance)
{
REALobject (*_fp)(REALobject, REALstring);
_fp = (REALobject(*)(REALobject, REALstring))REALInterfaceRoutine
(myInstance, Interface.name, "GetStringIdentifier");

REALobject retInstance = nil;

if (_fp)
{
retInstance = _fp(myInstance, theName);
}

REALUnlockString(theName);

api = GetAPIIdentifier(retInstance);
REALUnlockObject(retInstance); <------------------- necessary???
}
return api;
}

Based on the notion that the retInstance comes from the RB
environment, we really should not unlock it because once the event/
interface method goes out of scope, RB will reduce the refcount on
the retInstance, right?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Unlocking or not?
Date: 28.06.07 01:36 (Wed, 27 Jun 2007 19:36:40 -0500)
From: Jonathan Johnson

On Jun 27, 2007, at 7:33 PM, Alfred Van Hoek wrote:

>
> Based on the notion that the retInstance comes from the RB
> environment, we really should not unlock it because once the event/
> interface method goes out of scope, RB will reduce the refcount on
> the retInstance, right?

No, the event has already exited, and there is no further cleanup to
be done. Both objects stored in byref parameters and return values
must be unlocked to prevent leaking.

HTH,
Jon
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Unlocking or not?
Date: 28.06.07 01:37 (Thu, 28 Jun 2007 02:37:02 +0200)
From: Christian Schmitz
Alfred Van Hoek <<email address removed>> wrote:

> REALobject retInstance = nil;
>
> if (_fp)
> {
> retInstance = _fp(myInstance, theName);
> }
>
> REALUnlockString(theName);
>
> api = GetAPIIdentifier(retInstance);
> REALUnlockObject(retInstance); <------------------- necessary???

I think yes.
Functions return objects locked so the one using the result must unlock
it.

Gruß
Christian

-

Re: Unlocking or not?
Date: 28.06.07 03:32 (Wed, 27 Jun 2007 22:32:48 -0400)
From: Alfred Van Hoek

On Jun 27, 2007, at 8:36 PM, Jonathan Johnson wrote:

>
> On Jun 27, 2007, at 7:33 PM, Alfred Van Hoek wrote:
>
>>
>> Based on the notion that the retInstance comes from the RB
>> environment, we really should not unlock it because once the event/
>> interface method goes out of scope, RB will reduce the refcount on
>> the retInstance, right?
>
> No, the event has already exited, and there is no further cleanup to
> be done. Both objects stored in byref parameters and return values
> must be unlocked to prevent leaking.

hmm, if someone in such an event is creating a local instance

dim c as myClass = new myClass

and returns it

return c

then the refcount remains 1 if we don't unlock it? (According to
Christian)

The problem is that we do it as:
dim key as string = "myString"
dim c as myClass = myDict.value(key)
return c

If we don't unlock we leak sometimes, and if we do unlock, we crash
after a couple of times, because the destructor of the stored object
was called. The crash occurs then when myDict.value(key) is called.

This is when we use an Interface method, have to investigate if a
REALevent definition is stable.

ALfred
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Unlocking or not?
Date: 28.06.07 04:05 (Wed, 27 Jun 2007 22:05:48 -0500)
From: Jonathan Johnson

On Jun 27, 2007, at 9:32 PM, Alfred Van Hoek wrote:

>
> If we don't unlock we leak sometimes, and if we do unlock, we crash
> after a couple of times, because the destructor of the stored object
> was called. The crash occurs then when myDict.value(key) is called.

I would investigate the code immediately after adding the object to
the dictionary to ensure that there isn't an extraneous unlock call
around there. It is necessary to unlock on return, but I'm guessing
there is some other location that you're calling it that isn't correct.

Sorry I can't give any more specific issues -- these are the hardest
to debug. I'd suggest printing out each object address REALLock/
UnlockObject is called on, and seeing where the unbalanace lies.

HTH,
Jon
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>