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

[Nick]

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.


On 11/10/2011 09:00 AM, xforms-develo...@nongnu.org wrote:
> Send xforms-development mailing list submissions to
> xforms-de...@nongnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/xforms-development
> or, via email, send a message with subject or body 'help' to
> xforms-develo...@nongnu.org
>
> You can reach the person managing the list at
> xforms-devel...@nongnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xforms-development digest..."
>
>
> Today's Topics:
>
> 1. Re: Xforms& threads-functions& others
> (Denniston, Todd A CIV NAVSURFWARCENDIV Crane)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Nov 2011 10:56:59 -0500
> From: "Denniston, Todd A CIV NAVSURFWARCENDIV Crane"
> <todd.de...@navy.mil>
> To: "Development with and of XForms"<xforms-de...@nongnu.org>
> Subject: Re: [XForms] Xforms& threads-functions& others
> Message-ID:
> <DA1C49D1052ABF41939A...@naeacranez03v.nadsusea.nads.navy.mil>
>
> Content-Type: text/plain; charset="UTF-8"
>
>
>
>> -----Original Message-----
>> From: xforms-development-bounces+todd.denniston=navy...@nongnu.org
>> [mailto:xforms-development-bounces+todd.denniston=navy...@nongnu.org]
>> On Behalf Of Sergey Klimkin
>> Sent: Monday, October 10, 2011 15:06
>> To: xforms-de...@nongnu.org
>> Subject: Re: [XForms] Xforms& threads-functions& others
>>
>> Hi Alessandro,
>>
>>> Probably I don't see the full picture but I don't understand why you
>> need multithreading.
>>
>> Fuller picture looks so:
>> The program is intended for geodesists working in the fields. After
>> debugging at a workstation it will be transferred on the mobile device
>> (for example HP iPAQ-214 under control of OS Linux) therefore I am
>> guided in advance by "slow" processors).
>> Absence in the program of the menu and very big buttons also are
>> connected with small display HHPC and work in field conditions.
>>
>> My weak representation of details of work with external devices through
>> a serial port and almost full misunderstanding of a multithreading
>> speak
>> very simply:
>> 1. I not the programmer, I am a geodesist,
>> 2. The previous my programs are written under OS Windows, and there is
>> only COM1, COM2..., COMn. I didn't reflect on multithreading, as the
>> environment of working out of the program (Pelles-C) without my
>> participation has given this possibility.
>> 3. I use only 6 months Linux and only 3 months I try to master
>> programming (With without pluses) in Linux.
>>
> There are two things I would suggest you look at for the work you are doing, as they *MAY* make your work easier.
>
> 1) fl_add_io_callback, which allows you to get input from io devices, *when* the devices have input to give.
> http://xforms-toolkit.org/doc/xforms_6.html#SEC35
>
> 2) gpsd, which will take input from several kinds of gps/AIS/navigation devices and output it in one consistent format, plus at the same time keep your Network Time Protocol in sync.
> http://www.catb.org/gpsd/
> http://gpsd.berlios.de/
> https://savannah.nongnu.org/projects/gpsd
>
>
>
> <SNIP>
>> After connection with the external device (receiver or navigaror) is
>> established, the program accepts from it and writes down in a file the
>> continuous binary data flow with a reception interval in 1 second. For
>> this second it is necessary to execute parsing the accepted data and
>> still some mathematical transformations and to have time to write down
>> results in in 3 files (on an accessory of the data).
>>
>> Practically all GNSS-receivers are arranged so that form the block of
>> messages and send this block through the fixed interval of time -
>> usually 1 second. To read from port on 1 byte too slowly. The program
>> should "see" that the called messages having headings and the
>> terminations are received. It considerably accelerates the subsequent
>> data processing.
>>
>> At this time the user will be switched between program windows that:
>> 1. To establish start and stop for record of each point chosen on
>> district,
>> 2. To change if it is necessary height of the aerial of the receiver,
>> 3. To look level of signals from visible satellities in a firmament,
>> 4. To look an arrangement of satellities in a firmament.
>>
>> I represent it as 2 independent problems. Thus an exchange of the
>> program with the receiver it is desirable anything both not to
>> interrupt
>> in any way and not to stop at all.
>>
> <SNIP>
>
>
> ------------------------------
>
> _______________________________________________
> xforms-development mailing list
> xforms-de...@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/xforms-development
>
>
> End of xforms-development Digest, Vol 22, Issue 1
> *************************************************

[Jens Thoms Toerring]

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 ________ j...@toerring.de
\_______________________________ http://toerring.de

[Magnotta, Vincent A]

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 application.

Vince

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


________________________________________
From: xforms-development-bounces+vincent-magnotta=uiow...@nongnu.org [xforms-development-bounces+vincent-magnotta=uiow...@nongnu.org] on behalf of Jens Thoms Toerring [j...@toerring.de]
Sent: Thursday, November 10, 2011 1:45 PM

To: Development with and of XForms

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

________________________________
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.
________________________________