[Top][All Lists]

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

Re: [XForms] Xforms & threads-functions & others

From: alessandro basili
Subject: Re: [XForms] Xforms & threads-functions & others
Date: Tue, 11 Oct 2011 10:47:30 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 10/10/2011 9:06 PM, Sergey Klimkin wrote:
> 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.

IMHO GNU/Linux systems are amongst the most natural environment where
you can learn programming. I would avoid IDE for programming and stick
to a Makefile and an editor (like Emacs), but it is a choice (FYI Emacs
speedbar is a great tool to navigate through code in case you need).

> Probably multithreading not the most correct decision, but it that I
> have found in examples for libraries GTK+ in Linux.
> This method is quite efficient in the program which I have made in
> Code-Block with use of libraries GTK+
> Now (after very exact remarks Jens) multithreading also works in the
> program with libraries xforms.

I find multithreading fascinating, but I would definitely not recommend
that approach if you don't have much of programming experience.
Unfortunately having two threads that are sharing the same memory space
and run "in parallel", may arise a lot of problems when they access the
same resources (as in your case, since one thread is reading/writing
data, while the other is using/producing the data). I'm not an expert in
multithreading programming, but certainly you need to consider shared
memory access, I/O access, task scheduling, synchronization and race
conditions and much more. And bear in mind that multithreading is mostly
done to enhance performances and get the most out of your hardware/OS.

I found this link interesting and maybe helpful for you in case you want
to continue along this path:


> Program construction in style "server-client communication over the TCP
> stack" represents for me interest. But I do not know as it should look.
> Therefore, if it does not complicate you, some lines of a code on C-lang
> (can be with lines of comments) will be the most clear help.

I attached two simple programs, a client and a server, which communicate
over tcp. The advantage of this approach is that you need not to worry
about share memory or task scheduling, since it's the OS which does it
for you. In your case the server will perform the access to the serial
port while your client will interact with it.
Again, in principle the server could be multithreaded but I don't think
it is necessary, especially in your application.

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

To my mind 1 second is a big time interval and keeping the two
applications separated will help you a lot in having a working system,
since you can concentrate on two different problems separately.

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

I don't quite understand what you mean whit that.

> 08-10-2011 Terminal-log - example
> ---------------------------------
> address@hidden:~/projects/fdesign/surveyfd$ ./survey
> pixmap_file = /home/sklimkin/projects/fdesign/surveyfd/Garmin_iPAQ.xpm
> Function comport() in separated thread is running...
> PORTNAME=/dev/ttyS0
> WARNING! Press Ctrl+C to stop program!
> 16 bytes written to COM-port
> Binary file: /home/sklimkin/projects/fdesign/surveyfd/fileout.bin
> Bytes readed 537, found Garmin Message 0x33
> 2 Garmin commands is written!
> 605 bytes written in file
> 311 bytes written in file
> 311 bytes written in file
> ... ... ...
> 312 bytes written in file
> Segmentation fault

that is not a good sign, usually ;-)

> address@hidden:~/projects/fdesign/surveyfd$ 
> Depending on the receiver and from quantity of observable satellities,
> these lines can be from 300 to 2000 bytes of the binary data.

FWIK, depending on file system, usual access to file is in blocks of
4KB, so no difference in writing 300 or 2000.

> 605 bytes in the first line are 2 packages in the buffer serial-port.
> The program has begun dialogue with the receiver in the line:
>    sleep (2);  // in Sec
>    BytesRead = read(fd, bRead, BUFSIZE);
> For a confident finding of the message on that what receiver is
> connected to port.
>> You can use fl_add_timeout() or fl_add_timer() to invoke the state
> machine if the comm. is very lengthy
> If it does not complicate you, some lines of a code on C-lang (can be
> with lines of comments) will be the most clear help.

I should mention that I found fdesign a very nice tool to check how your
interface will look like, but I will never use the source code produced
by fdesign, since the code I produce is much more maintainable and
readable than the one produced by the designer.

If you want to stick to fdesign I cannot advise how to add a timer or
timeout, but if you want I can point you to our libraries (which are not
very well documented though).

Attachment: client-study.c
Description: Text Data

Attachment: server-study.c
Description: Text Data

reply via email to

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