Xlib calls and Multi-Threaded Apps



Thought I'd add my two cents here:

Expecting an X server to honor a multi-threaded request is always an iffy
proposition.

First, you have no guarantee that the X server you will be executing
against will actually understand the call, not all versions existing in
the world are up-to-date in this regard.

Second, imho, this is not implemented terribly well anyway at the X level.
 You will lose inordinate amounts of time trying to get your head around
why things don't work the way you cognitively think they should.  There is
nothing more unenjoyable than trying to decipher Xlib error messages. And
simply running the application synchronously is no answer here, your
experience of being thoroughly frustrated merely exists in slow motion.

Luckily, there are few, if any, applications which require this sort of
behaviour anyway.  Instead of thinking it's easier to write multi-threaded
applications which can draw in multiple threads (it's not), use the
following paradigm:

    1)  Do all drawing in the main thread only
    2)  Use other threads only for background sorts of processing:
communications, database requests, data analysis, etc.
    3)  Once the background thread has completed its task, use
g_idle_add() to issue a request back to the main thread that a drawing
needs to be updated, i.e., call the routine that is responsible for
drawing to your background pixmap.

In essence, your application is multi-threaded, however, in the context of
communications with the X server it remains single-threaded.  Maintaining
this illusion with X will seriously increase the likelihood that your
application will work "everywhere".

In other words, do not rely on the X-server to keep your multi-threaded
app in a sane state 100% of the time; multi-threading is tricky enough
without including X in the problem.

cheers,

richard

On Nov 29, 2007 2:16 AM, Michael Lamothe <michael lamothe gmail com> wrote:

    Hi,

    I think that they do call XInitThreads() but libraries such as
    xine-lib break if you don't call it first.  Don't know why.  If your
    GTK app does not use and X based (Non GDK/GTK) libraries then maybe
    this isn't your problem.

    Maybe, as Micah pointed out, this might be a simple problem with you
    not writing a thread safe application.  Is your application
    multi-threaded?

    Thanks,

    Michael


    On 29/11/2007, Andres Gonzalez <gonzo agoralabs com> wrote:
    > Thank you Michael for your response.
    >
    > What was confusing to me was that I was not directly using X but Gtk.
    > But I am using g_thread_init() and g_thread_create(). I am assuming
    > that g_thread_init() calls XInitThreads() so your answer is very
    > helpful.
    >
    > Thanks again,
    >
    > -Andres
    >
    >
    >
    >
    > > Every time I see this it's because I've called a multi-threaded
    > > library that requires XInitThreads() to be called.  This needs to be
    > > called before all other X functions.
    > >
    > > Hope that helps.
    > >
    > > Thanks,
    > >
    > > Michael
    > >
    > >> On 28/11/2007, Andres Gonzalez <gonzo agoralabs com> wrote:
    > >> Hi,
    > >>
    > >> I get the following error message when displaying a dialog. Any
    > ideas
    > >> as to what is causing it?
    > >>
    > >> Xlib: unexpected async reply (sequence 0x6cb)
    > >>
    > >> Thanks,
    > >>
    > >> -Andres




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]