This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: [PATCH] Re: pthread
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.