On 7 Sep 2006, at 16:55, Wim Oudshoorn wrote:
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.
Thanks ....I agree that it seems unsafe to use a simple lock, so we do need to have a recursive one. Checking the source code, it seems I forgot to change back from recursive to non-recursive anyway, so the current code in svn should be OK even in the case that an application invalidates a connection during its creation.
_______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
