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, address@hidden wrote:
> Send xforms-development mailing list submissions to
>         address@hidden
>
> 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
>         address@hidden
>
> You can reach the person managing the list at
>         address@hidden
>
> 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"
>         <address@hidden>
> To: "Development with and of XForms"<address@hidden>
> Subject: Re: [XForms] Xforms&  threads-functions&  others
> Message-ID:
>         <address@hidden>
>         
> Content-Type: text/plain;       charset="UTF-8"
>
>
>
> > -----Original Message-----
> > From: address@hidden
> > [mailto: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
> > 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/xforms-development
>
>
> End of xforms-development Digest, Vol 22, Issue 1
> *************************************************