xforms-development
[Top][All Lists]
Advanced

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

Re: [XForms] xforms-development Digest, Vol 22, Issue 1


From: Jens Thoms Toerring
Subject: Re: [XForms] xforms-development Digest, Vol 22, Issue 1
Date: Thu, 10 Nov 2011 20:45:17 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

On Thu, Nov 10, 2011 at 10:18:41AM -0800, Nick wrote:
> I can relate to this problem, since I ran into it with my lxarduino
> project (on Sourceforge). The application uses two threads, one for
> reading from the serial or usb port, and one for processing and
> displaying of the results. The input reading thread is timed by the
> blocking reading process: it waits for a buffer full of data to
> become available from the port, picks up the buffer content and does
> only some minimal processing, to make sure it is ready for the next
> reading cycle. The main processing and GUI part is executed when
> triggered through user interaction or in regular intervals through
> the xforms timer (fl_add_timer). These two processes are
> asynchronous; therefore I need two threads. It can be desirable for
> the reading thread also to be able to modify some GUI settings, like
> on error or overrange condition. When updates to the GUI happen
> simultaneously from the two threads,  the current application dies
> with a message: "X Error of failed request:  BadRequest (invalid
> request code or no such operation)". I have managed to work around
> the problem, and will update the application on Sourceforge soon.
> Since the clash happens seldom and in a random manner, it is
> difficult to debug, and obviously a serious, kind of hidden problem.
> It is highly desirable to have xforms deal with the situation,
> either by allowing for multithreading, or by handling it in a
> graceful manner.

Sorry, but I fear that I will have to disappoint you. To start
with, XForms is definitely not thread-safe, and making it that
would, I guess, require more or less a complete rewrite. This
makes writing applications using different threads calling
XForms functions nearly impossible (or you would need to pro-
tect all calls of XForms functions by a mutex).

And since XForms itself isn't thread-safe it doesn't make any
attempt to initialize X11 to be thread-safe (which nowadays
can be done but, as far as I know, wasn't posssible when the
XForms library was written). And that's were your X errors are
coming from: while you seem to be lucky not to have gotten the
XForms library too confused you managed to upset X which didn't
expect intermingled requests from different threads. Of course,
those X errors happen at seemingly random times because with
threads you can't forsee which is running at what time and if
they by chance might try to use X functions at the same time.

As far as I understand it at the moment even if X11 would be
initialized to be thread-safe in principle (i.e. by calling
XInitThreads()) this wouldn't help at all since then all
calls of X11 functions in XForms would have to be rewritten
to lock and unlock the display. And even that would only help
for the rather unusual case where one thread in an application
exclusive uses X11 functions, e.g. for drawing into a canvas,
but no XForms functions, while some other thread deals with the
"normal" GUI interactions - XForms itself would still be not
thread-safe.
                             Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]