[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: Nick
Subject: Re: [XForms] xforms-development Digest, Vol 22, Issue 1
Date: Thu, 10 Nov 2011 10:18:41 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11

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, address@hidden wrote:
Send xforms-development mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

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"
To: "Development with and of XForms"<address@hidden>
Subject: Re: [XForms] Xforms&  threads-functions&  others
Content-Type: text/plain;       charset="UTF-8"

-----Original Message-----
From: address@hidden
On Behalf Of Sergey Klimkin
Sent: Monday, October 10, 2011 15:06
To: address@hidden
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
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.

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.

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
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
in any way and not to stop at all.



xforms-development mailing list

End of xforms-development Digest, Vol 22, Issue 1

reply via email to

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