[drats_users] Thread 4 on Windows using 30 to 50% CPU, GPS Parsing?

[John E. Malmberg]

On 2/19/2013 10:14 PM, Dan Smith wrote:
>> Thread trace is:
>>      _match_gps [transport.py:190]
>>      parse_gps [transport.py:226]
>>      worker [transport.py:304]
>>      run [threading.py:504]
>>      _bootstrap_inner [treading.py:551]
>>      _bootstrap [threading.py:524]
>
> Thanks for digging in.
>
> Looking at the code, I'm not sure how it could get stuck in either of
> the gps functions there. If it did, all traffic in and out would cease
> as well, which I haven't heard anyone report. I tend to expect it's
> spinning higher than that.

Any suggestions on how to proceed with the debugging?

Right now, I have the thread paused and it does not seem to be affecting 
the chat and event log windows at all.

Stepping through the thread shows that it is looping through the following:

      while self.enabled:
         try:
            self.get_input()
             (returns with nothing read, so self.input is "")

         self.parse_blocks()
         self.parse_gps()

         if self.inbuf and self.compat_is_time():
            (self.inbuf == "", so block is skipped)
         try:
             self.send_frames()
                 (self.outq.dequeue() returns None,
                  so this function does nothing).

So for some reason, this thread is looping, polling for input with out 
any delay.


One other thing is that it takes about 15 minutes of run-time before the 
excessive CPU starts being seen.  The amount of traffic seen in the chat 
window does not seem to affect this time.

I have not timed it with precision, but it is very repeatable.

Regards,
-John