Sun's Xlib threading fixes

[I couldn't find this for this bug.]

XFindContext in Xlib was calling _XLockMutex with an uninitialized mutex lock structure. The new version of XInitThreads activates the locking functions at any time, even after displays have been created.

In this new case, the context structure was created prior to XInitThreads being invoked. As a result, the display contained an opaque pointer to this context structure, which still contained an uninitialized lock structure.

The solution was to explicitly set the lock structure pointer to NULL (as a flag) when creating the context, then check for NULL before locking. If NULL is found and threads are now enabled, then the structure gets reinitialized to the correct mutex lock structure before the lock call.

Another area besides the functions in Context.c are the functions in Xrm.c. A similar fix was added to them as well.

The trace of sdtimage when the problem occurs is as follows:

(dbx) threads
*>    t@1  a l@1  ?()   signal SIGINT   in __sigprocmask()
      t@2  b l@2  ?()   running                 in _signotifywait()
      t@3         ?()   sleep on (unknown)      in _swtch()
      t@4  b l@4  ?()   running                 in _lwp_sema_wait()

(dbx) lwps        
*>l@1 signal SIGINT in __sigprocmask()
  l@2 running          in _signotifywait()
  l@3 running          in ___lwp_cond_wait()
  l@4 running          in _lwp_sema_wait()
  l@5 running          in _door_return()

(dbx) where
current thread: t@1
  [1] __sigprocmask(0xdf88d8e0, 0xf8df88d8, 0x87f8df88), at 0xdf88b551
  [2] __bounceself(), at 0xdf884675
  [3] _sigon(), at 0xdf8843a5
  [4] _mutex_adaptive_lock(), at 0xdf8821c3
  [5] _pthread_mutex_lock(), at 0xdf881fa4
  [6] mutex_lock(), at 0xdfbed931
  [7] _XLockDisplay(), at 0xdfd4d6cd
  [8]  at 0xdfd22839
  [9] _Ximp_RegKeyPressed(), at 0xdebebd99
  [10] _Ximp_KeypressFilter(), at 0xdebebfd4
  [11] _Ximp_XimFilter_Keypress(), at 0xdebedc27
  [12] XFilterEvent(), at 0xdfd4d0df
  [13] _XtDefaultDispatcher(), at 0xdfd80815
  [14] XtDispatchEvent(), at 0xdfd80a29
=>[15] main(argc = 2, argv = 0x8047a94), line 716 in "imagetool.c"

(dbx) where t@2
current thread: t@2
  [1] _signotifywait(0xdf808000, 0xdf8080, 0xdf80), at 0xdfbaac1c
  [2] _dynamiclwps(), at 0xdf884c09

(dbx) where t@3
current thread: t@3
  [1] _swtch(), at 0xdf88108d
  [2] _sigon(), at 0xdf8843a5
  [3] _reaper(), at 0xdf884024

(dbx) where t@4
current thread: t@4
  [1] _lwp_sema_wait(0xdf606000, 0xdf6060, 0xdf60), at 0xdfbaab61
  [2] _tdb_agent(), at 0xdf889c1d

From my examination of the problem, and a little searching about in the X11 sources. It looks like XFilterEvent(), is doing an XLockDisplay and calling the filter function, in Ximp (extract from XFilterEvent):

Bool
XFilterEvent(ev, window)
    XEvent *ev;
    Window window;
{
    ...

    LockDisplay(ev->xany.display);
    for (p = ev->xany.display->im_filters; p != NULL; p = p->next) {
    if (win == p->window) {
        if ((mask & p->event_mask) ||
        (ev->type >= p->start_type && ev->type <= p->end_type)) {
        ret = (*(p->filter))(ev->xany.display, p->window, ev,
                      p->client_data);
        UnlockDisplay(ev->xany.display);
        return(ret);
        }
    }
    UnlockDisplay(ev->xany.display);
    return(False);
}

After this also does a LockDisplay, but I think XGetWindowAttributes(), it's here, waiting for the semaphore to be released (extract from XGetWindowAttributes):

Status XGetWindowAttributes(dpy, w, attr)
     register Display *dpy;
     Window w;
     XWindowAttributes *attr;
{
    xGetGeometryReply rep;
    register xResourceReq *req;
    register int i;
    register Screen *sp;
    _XAsyncHandler async;
    _XWAttrsState async_state;

    LockDisplay(dpy);
    GetResReq(GetWindowAttributes, w, req);

    ...
    
}

I tried to remove LockDisplay/UnlockDisplay statements from XFilterEvent function and rebuilt the library. With this change, the bug was fixed. I believe this is better fix than doing UnlockDisplay/LockDisplay around XGetWindowAttributes inside XIM module, and there is no other side effect. In non-threaded environment, this change does not affect anything. XIM people told me that the input method module does not touch any of the display structure members, so it is safe to remove the locks.

The cause of the problem is that in multithread environment some data in XLookupColor() and XAllocNamedColor() can be accessed/motified at same time by multi threads. Adding some lock and unlock code to make sure only one thread can access the data at one time fixed the problem.