Re: Please test new NSLock implementation!

[David Chisnall]

On 2 Sep 2009, at 16:39, Richard Frith-Macdonald wrote:

> Any clues on getting this working in mswindows?
>
> Grabbing the latest executable from a sourceforge mirror, I put the  
> headers in mingw/include and the libraries in mingw/lib ...
> That was sufficient for the headers to be found, but I got tis ..
>
> Linking library libgnustep-base ...
> obj/NSLock.m.o: In function `i_NSLock__init':
> C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165:  
> undefined reference to `_imp__pthread_mutexattr_init'
> C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165:  
> undefined reference to `_imp__pthread_mutexattr_settype'
> C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165:  
> undefined reference to `_imp__pthread_mutex_init'
>
> and lots more similar messages.
>
> I'm guessing that gnustep-make needs updating to find the thread  
> library and add it?  Do you know what the link arguments should be?

Gregory built it on Windows last night, so he can answer this better  
than me, but you probably need to add -lpthread to LD_FLAGS if it's  
not there already.

> Another thing ...do we need to build/use a different version of the  
> objc runtime too?  Presumably the runtime needs to be built with the  
> same thread library as the rest of the system.

No.  We still use objc_mutex_lock when locking the runtime and we call  
the relevant runtime functions for registering new threads[1].  The  
runtime itself never spawns thread and doesn't use anything other than  
mutexes so it doesn't matter if we mix pthread-wrappers-around-windows- 
mutexes with objc-wrappers-around-windows-mutexes[2] as long as we  
don't mix calls (e.g. don't try to use pthread_mutex_lock on the  
runtime's mutexes or objc_mutex_lock on a pthread mutex).  Both wrap  
win32 mutexes on Windows, so both can be used for synchronisation  
independently within the same program.

David

[1] Note that these functions are complete nonsense.  They set two  
variables, one of which is unused in the runtime and the other is used  
once in sarray.c, and in the one place where it is used the wrong  
variable is used so the runtime is only running non-thread-safe code  
when the number of threads is exactly 1.

[2]  This one is particularly stupid, by the way.  A mutex on windows  
is always recursive, but the libobjc abstraction layer assumes that  
they are not, so implements recursive mutexes on top of non-recursive  
mutexes on top of recursive mutexes.  Yay for coherent design!  I will  
try to fix this soon.