[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please test new NSLock implementation!

From: David Chisnall
Subject: Re: Please test new NSLock implementation!
Date: Fri, 4 Sep 2009 21:15:09 +0100

On 4 Sep 2009, at 23:04, Fred Kiefer wrote:

The problem there is that the ObjC runtime doesn't include a recursive
lock mechanism. This is one of the strong points in David's code, he
uses the native pthread support for recursive locks, which makes
implementing NSRecursiceLock so much easier.

Actually, this is incorrect. The ObjC runtime ONLY includes recursive locks. If the existing code was written on the assumption that this is not the case, then it was wrong. Windows, similarly, only provides recursive locks, but the abstraction layer implements the recursive behaviour in the portable code, so these are still used as if they were non-recursive mutexes, which is painfully inefficient and error- prone.

Using pthread directly in
base is OK, but we should hide it from users of base and not spill it on
to user application code.

I agree in principle, but so far all of the proposed solutions have been worse than the perceived problem. At worst, we are leaking some symbols into the user's code symbol table, but given that these are symbols are already going to be provided to the linker, this seems like a minor matter - the worst it does is provide a little error checking and throws errors early if they declare functions that match the pthread functions (which, given that all of the pthread functions and types are prefixed with pthread_ seems unlikely).

Note that we already do this with several of the libobjc headers; GNU runtime functions are exposed in all code that imports Foundation.h on GNUstep, while OS X requires the runtime headers to be explicitly included for the equivalent functionality to be accessed. No one, to my knowledge, has objected to this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]