[Gambas-user] High CPU usage when using serialport component

[Benoît Minisini]

Le 11/08/2012 15:12, Christer Johansson a écrit :
>
>
>> From: Benoît Minisini [mailto:gambas at ...1...]
>>
>> As the SerialPort example asks for DTR, RNG, ... Change events, the
>> gb.net component watches if serial port file device is ready for writing
>> and uses that to watch the serial port signals.
>>
>> So I guess the watch callback is called again and again (i.e. the serial
>> port device is always ready for writing). There is a one millisecond
>> sleep inside the callback so that not to much CPU is consumed, but RPi
>> is a slow machine.
>
> Thanks for the input Benoît, however what I find strange is that when I test
> the same code (a simple CLI only opening /dev/ttyUSB0) on my other ARM
> SBC running Debian Lenny it consumes close to nothing (i.e htop shows CPU%
> as 0.0% all the time) using the serialport, below is stat from my NSA-220
> and
> the listed "gateway" process have been running for several weeks...
>
>     PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
>    30456 root      15   0 13336  2072   724 R  0.0  1.6  0:12.48 gbr3
> ./gateway.gambas
>
> And the ARM CPU in NSA-220 is quite a bit weaker than the one in RasPi,
> just for reference something like 330 vs 790 BogoMIPS so something strange
> is going on, maybe it's something with the RasPi HW??
>
>> To confirm that, can you use gdb to run the exemple, hit
>> CTRL+C during the high CPU usage, and show me what the backtrace is then?
>
> Hope I did things correctly and it helps you to get some clues?
>
> christer at ...2912...:~/Gambas 3/Projekt/SerialPort$ gdb gbx3
> GNU gdb (GDB) 7.0.1-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/gbx3...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/gbx3
> [Thread debugging using libthread_db enabled]
> ^C
> Program received signal SIGINT, Interrupt.
> 0x400efcfc in nanosleep () from /lib/libpthread.so.0
> (gdb) bt
> #0  0x400efcfc in nanosleep () from /lib/libpthread.so.0
> #1  0x41aa1534 in ?? () from /usr/lib/gambas3/gb.net.so
> #2  0x41aa1534 in ?? () from /usr/lib/gambas3/gb.net.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
> Also attaches a screenshot...
>
> /CJ
>

Can you try:

1) By using gb.qt4 instead of gb.gtk?

2) By commenting all SPort1_xxxChange event handlers in the example 
source code?

-- 
Benoît Minisini