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 _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
