[Top][All Lists]

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

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

From: Magnotta, Vincent A
Subject: Re: [XForms] xforms-development Digest, Vol 22, Issue 1
Date: Fri, 11 Nov 2011 01:35:35 +0000

We have written an application that did achieve the use of two threads with 
Xforms. In this application we created threads and then used one thread to 
initialize Xforms on one thread and used the other thread to run Tcl/Tk. The 
two threads then used shared memory and an pipe to communicate. While not 
optimal, it provides a way to possibly meet the demands of the proposed 


Associate Professor
Department of Radiology
0453-D JCP
200 Hawkins Drive
Iowa City, IA 52242
E-mail: address@hidden
Phone: 319-356-8255 Fax: 319-353-6275
Website: http://www.healthcare.uiowa.edu/Radiology

From: address@hidden address@hidden on behalf of Jens Thoms Toerring 
Sent: Thursday, November 10, 2011 1:45 PM
To: Development with and of XForms
Subject: Re: [XForms] xforms-development Digest, Vol 22, Issue 1


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
                             Best regards, Jens
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de

Notice: This UI Health Care e-mail (including attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and 
may be legally privileged.  If you are not the intended recipient, you are 
hereby notified that any retention, dissemination, distribution, or copying of 
this communication is strictly prohibited.  Please reply to the sender that you 
have received the message in error, then delete it.  Thank you.

reply via email to

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