[PATCH] Re: pthread

Alan Hourihane alanh@fairlite.demon.co.uk
Sat May 5 10:37:00 GMT 2001


On Sun, May 06, 2001 at 01:35:41AM +1000, Robert Collins wrote:
> if _Xglobal_lock is an initialised mutex, it is really a pointer into
> memory allocated by the cygwin dll. That shouldn't be a problem per se.
> Are you expecting _Xglobal_lock to be NULL _before_ it's initialised?
> 
_Xglobal_lock is defined as NULL _before_ it's initialized - Yes.

> One thing to note is that shared mem mutexs aren't supported as yet
> (interactions with condition variables and some nasty race conditions).
> They will be and I've test code here that works but its fugly. I need to
> make it clean before I consider submitting a patch.
> 
Mmmm.

> I'm happy to contribute my limited dll expertise... but I'm still not
> quite clear on the problem. You've got two symbols, Xglobal_lock_p and
> Xglobal_lock. Functions (? inside/outside) the library are seeing the
> two symbols as having identical values, not as a) a pointer to the
> second symbol, and b) NULL/a lock count/??
> 
_Xglobal_lock_p is the pointer to _Xglobal_lock. _Xglobal_lock is defined
as NULL _before_ any threads are created.

It seems the DLL is creating the reference to _Xglobal_lock as _Xglobal_lock_p
and therefore when libXext tries to find the value of _Xglobal_lock it
really gets it's pointer reference rather than it's actual value.

I don't know how the dllwrap tools handles the _p =  fudging in the
.def file. 

And I don't think it's a pthread issue at all. We're not even creating any
threads (twm doesn't create any threads).

Alan.



More information about the Cygwin-xfree mailing list