Re: [PATCH] Re: pthread

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Suhaib Siddiqi" <ssiddiqi@inspirepharm.com>
To: "'Alan Hourihane '" <alanh@fairlite.demon.co.uk>; "'Robert Collins
'" <robert.collins@itdomain.com.au>
Cc: <cygwin-xfree@sources.redhat.com>
Sent: Sunday, May 06, 2001 12:54 AM
Subject: RE: [PATCH] Re: pthread


> _XLIBINT_ and NeedLibInsideFlag did not help.
> However I can compile win32-x11 with pthread from
> (http://sources.redhat.com/win32-x11 and pthread from win32 from
> sourceware), and no crashes ;-)

Can you compile Xfree86 with the source win32 pthreads? fork() may
break, but if that works, you could tell me whats wrong with my code and
I'll write to your spec to fix it. (ahh the beauty of clean room r/e).

> I would consider it the pthread issue with Cygwin.

This isn't a valid comparison. a) win32-x11 is a different server. b) I
think the problem is a variable-in-library problem from what Alan has
described.

Having said that it _may_ be a pthread source fault. It's new code, not
stable and has known incompleteness, races and bugs. But we can't import
code without a copyright assignment to redhat, so....

read on.. more below.

> Suhaib
>
> -----Original Message-----
> From: Alan Hourihane
> To: Robert Collins
> Cc: cygwin-xfree@sources.redhat.com
> Sent: 5/4/2001 12:06 PM
> Subject: Re: [PATCH] Re: pthread
>
> O.k. I now know what's happening...
>
> In the X11-def.cpp we have the following definitions...
>
>  _Xdebug_p=_Xdebug CONSTANT
>  _XCreateMutex_fn_p=_XCreateMutex_fn CONSTANT
>  _XFreeMutex_fn_p=_XFreeMutex_fn CONSTANT
>  _XLockMutex_fn_p=_XLockMutex_fn CONSTANT
>  _XUnlockMutex_fn_p=_XUnlockMutex_fn CONSTANT
>  _Xglobal_lock_p=_Xglobal_lock CONSTANT
>
> The _Xdebug and _Xglobal_lock definitions are global variables.
Whereas
> the others are functions.
>
> What's happening is that in libXext it eventually ends up calling the
> _XLockMutex(_Xglobal_lock) function. Then, when threads are not used,
> which
> is normal in twm's case as it never creates any threads - It should
just
> do
> nothing.
>
> But what happens now is that _Xglobal_lock is used as a check to see
> if threads are enabled. If this returns a non-NULL value it assumes
that
> threads are used. Bang!
>
> _Xglobal_lock 's value is basically being defined as it's pointer in
> memory
> space. Therefore this is where this 0xd1x.... value comes from. It's
not
> the actual value of _Xglobal_lock.

huh? a mutex in cygwin is essentially a pointer. (We aren't the OS, so
we can't just index into a table of system wide mutex's).

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?

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.

> I'm not a DLL building expert, but we need to fix the pointer/value
> mismatch.
> Whether this can be done with fixing the X11-def.cpp I don't know.
There
> are some comments in Xlibint.h about defining _XLIBINT_ through the
use
> of the NeedLibInsideFlag (in cygwin.rules). Whether this can help is
> another
> route.
>
> I need a DLL guru.

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/??

Rob

> Alan.
>