Re: Please test new NSLock implementation!

[Fred Kiefer]

David Chisnall schrieb:
> 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.

I really don't know, I was assuming the underlying mutex in objc was
only guaranteed to be a non-recursive one, as we implemented recursive
locks on top of normal ones. I also couldn't find a reference for this
and wont be looking through all the different implementations the
runtime offers here to decide which is true, so I just take your word here.

>> 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.

This is different, although I also would prefer to avoid this.

But if there isn't any chance that I can convince to to take back the
binary incompatible change you made (but who would ever subclass
NSLock?), by adding a bit more code to the NSLock.m file, I rather give
up here.
You did understand that for FreeBSD and other systems where
pthread_mutex_t fits into a pointer this wouldn't even be a runtime
overhead, as no extra indirection is needed, didn't you?

Fred