This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]