Re: Another multithreading bug (I think)

[Wim Oudshoorn]

Richard Frith-Macdonald <richard@tiptree.demon.co.uk> 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.