X and Multithread Compatible Issue - Xwindows

This is a discussion on X and Multithread Compatible Issue - Xwindows ; Hi All, I have a question with some X stuff doesn't work after pthread_cancel. First question: are those Xlib functions cancellation point? My guess is that Xlib functions are high level functions composed of system calls, so if it has ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: X and Multithread Compatible Issue

  1. X and Multithread Compatible Issue

    Hi All,

    I have a question with some X stuff doesn't work after pthread_cancel.

    First question: are those Xlib functions cancellation point? My guess
    is that Xlib functions are high level functions composed of system
    calls, so if it has system function inside that's cancellation point
    then the Xlib function is a cancellation point, is that reasonable
    assumption?

    Now the question is that since in MT programming using Xlib/Xt, most
    of those Xlib/Xt functions use it's own lock (acquire lock on enter
    and release on exit), if the thread is cancelled while making the
    Xlib/Xt call, how can I get the lock to release? I can not use
    XUnlockDisplay or XtAppUnlock if I don't know I have the lock, right?
    So the solution is to guard those Xlib/Xt function calls against
    cancellation?

    In my particular case, I have a thread that does very complicated
    stuff, it also has a little code that uses XSendEvent to send message
    to some other process on test result etc, I have the thread's cleanup
    handler to call XCloseDisplay (the thread does XOpenDisplay at the
    beginning), test shows that sometimes the XCloseDisplay hangs, here's
    an example traceback (on Solaris 8 w/ X11R6):

    ----------------- lwp# 7 / thread# 12 --------------------
    ff01cdc4 _XFlushInt (4677080, ff09d24c, ff09a000, 0, 4677080, 0) +
    108
    ff01fc00 XFreeGC (4677080, 0, 4682658, f8b6e000, 0, e) + 7c
    ff023bf4 XCloseDisplay (4677080, 50, 1, fefecb72, 13a180, 13ab20) +
    48
    f96505d4 exec_cleanup_handler (0, f96505a0, f8b5b808, f965075c,
    fefcdbec, 1) + 34
    f8b5b7f8 _ex_clnup_handler (0, f8a53d10, f8b5b808, f965075c, 1,
    fe401000) + 10
    f8b5b728 _thread_start (0, 0, 0, 0, 0, 0) + 40


    I'm not sure how can this happen, my assumption is that somewhere my
    thread get cancelled while it's making a Xlib/Xt call.

    Anyone can help?

    Thanks.

    -OJ

  2. Re: X and Multithread Compatible Issue

    OutsiderJustice wrote:
    >Hi All,
    >
    >I have a question with some X stuff doesn't work after pthread_cancel.
    >
    >First question: are those Xlib functions cancellation point? My guess
    >is that Xlib functions are high level functions composed of system
    >calls, so if it has system function inside that's cancellation point
    >then the Xlib function is a cancellation point, is that reasonable
    >assumption?
    >
    >Now the question is that since in MT programming using Xlib/Xt, most
    >of those Xlib/Xt functions use it's own lock (acquire lock on enter
    >and release on exit), if the thread is cancelled while making the
    >Xlib/Xt call, how can I get the lock to release? I can not use
    >XUnlockDisplay or XtAppUnlock if I don't know I have the lock, right?
    >So the solution is to guard those Xlib/Xt function calls against
    >cancellation?
    >
    >In my particular case, I have a thread that does very complicated
    >stuff, it also has a little code that uses XSendEvent to send message
    >to some other process on test result etc, I have the thread's cleanup
    >handler to call XCloseDisplay (the thread does XOpenDisplay at the
    >beginning), test shows that sometimes the XCloseDisplay hangs, here's
    >an example traceback (on Solaris 8 w/ X11R6):

    [snip]

    Library calls must not be cancelled asynchronously. In your example,
    you have a mutex that is not freed as the outward indication. You
    might be able to figure out how to free it, but that would still leave
    the data that it is protecting in an indeterminant state.

    You might be able to avoid this by holding all three X locks
    (XLockDisplay, XtAppLock, XtProcessLock) when you do the cancel, but a
    far better solution is to re-engineer the code to not attempt the
    asynchronous cancellation.

    This is not just a problem with X -- you will have similar failures
    with libc and others, even if they are advertised as thread safe.


  3. Re: X and Multithread Compatible Issue

    kbr@pangea.ca (Kip Rugger) wrote in message news:...
    > OutsiderJustice wrote:
    > >Hi All,
    > >
    > >I have a question with some X stuff doesn't work after pthread_cancel.
    > >
    > >First question: are those Xlib functions cancellation point? My guess
    > >is that Xlib functions are high level functions composed of system
    > >calls, so if it has system function inside that's cancellation point
    > >then the Xlib function is a cancellation point, is that reasonable
    > >assumption?
    > >
    > >Now the question is that since in MT programming using Xlib/Xt, most
    > >of those Xlib/Xt functions use it's own lock (acquire lock on enter
    > >and release on exit), if the thread is cancelled while making the
    > >Xlib/Xt call, how can I get the lock to release? I can not use
    > >XUnlockDisplay or XtAppUnlock if I don't know I have the lock, right?
    > >So the solution is to guard those Xlib/Xt function calls against
    > >cancellation?
    > >
    > >In my particular case, I have a thread that does very complicated
    > >stuff, it also has a little code that uses XSendEvent to send message
    > >to some other process on test result etc, I have the thread's cleanup
    > >handler to call XCloseDisplay (the thread does XOpenDisplay at the
    > >beginning), test shows that sometimes the XCloseDisplay hangs, here's
    > >an example traceback (on Solaris 8 w/ X11R6):

    > [snip]
    >
    > Library calls must not be cancelled asynchronously. In your example,
    > you have a mutex that is not freed as the outward indication. You
    > might be able to figure out how to free it, but that would still leave
    > the data that it is protecting in an indeterminant state.
    >
    > You might be able to avoid this by holding all three X locks
    > (XLockDisplay, XtAppLock, XtProcessLock) when you do the cancel, but a
    > far better solution is to re-engineer the code to not attempt the
    > asynchronous cancellation.
    >
    > This is not just a problem with X -- you will have similar failures
    > with libc and others, even if they are advertised as thread safe.



    Thanks a lot for the reply, but I'm not using async cancellation, I
    use the default deferred cancellation, could the thread still be
    cancelled while inside the X call?

    I have tried all sorts of things:

    - XLockDisplay and then XUnlockDisplay inside the thread cleanup
    handler, but it hangs in the unlock part sometimes
    - XtAppLock and then XtAppUnlock inside the thread cleanup handler,
    same problem.

    For my particular case, the only way I can make it work is to forget
    about the old X connection (don't call XCloseDisplay), after the
    thread is cancelled and a new thread is started to assume it's job,
    let the new thread always call XOpenDisplay to start a new X
    connection, that seems working fine, the only problem is some memory
    leak from not closing the old connection.

+ Reply to Thread