Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> On 7 Sep 2006, at 12:23, Richard Frith-Macdonald wrote:
> I've committed a change which moves the call to -gcFinalise into -
> dealloc and replaces the implementation of -release with:
>
> {
> M_LOCK(connection_table_gate);
> if (NSDecrementExtraRefCountWasZero(self))
> {
> NSHashRemove(connection_table, self);
> M_UNLOCK(connection_table_gate);
> [self dealloc];
> }
> else
> {
> M_UNLOCK(connection_table_gate);
> }
> }
>
> Can you see any problems with this?
> I don't think -retain needs to lock the gate, and as long as we are
> only locking in the -release method as above, I think we can avoid
> using a recursive lock (as I don't think we call -release inside any
> region where we already lock the gate), but I may have missed
> something.
I think you are right that the retain does not need the lock.
However, there needs to be a recursive lock because in the method:
- initWithReceivePort:sendPort:
the connection_table_gate locks the region:
/* Here is the GNUstep version, which allows the delegate to specify
a substitute. Note: The delegate is responsible for freeing
newConn if it returns something different. */
if ([del respondsToSelector: @selector(connection:didConnect:)])
{
self = [del connection: parent didConnect: self];
}
The comment suggest that usercode could well try to release the connection.
Wim Oudshoorn.
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
