Re: Please test new NSLock implementation!

[David Chisnall]

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.

David