[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] stuck in consume_packets/multipoll loop
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] stuck in consume_packets/multipoll loop |
Date: |
Wed, 20 Nov 2013 09:36:43 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Bernd Ocklin <address@hidden>:
> In order to loop forever in gpsd_multipoll()'s for-loop over packet
> fragments you need to have
>
> 1. "slow" gpsd host (400MHz embedded)
> 2. chatty nmea2000 device
> 3. single-frame CAN transmissions (e.g. PGN
>
> Due to 1. and 2. every nmea2000_get() returns > 0.
> Due to 3. every packet is complete, outbuflen > 0.
>
> In gpsd_poll() this qualifies for PACKET_SET. In gpsd_multipoll()
> this means != NO_DATAIS and & PACKET_SET != 0. Thus
> gpsd_multipoll() just loops and gpsd is locked into the nmea 2000
> device.
>
> An ugly hack would obviously be to make every second nmea2000_get()
> call a no-op returning 0. But a simple
>
> /* give other devices a chance */
> if (changed & PACKET_SET)
> break;
>
> at the end of the loop fixed the problem for me. Not 100% sure about
> side effects for other cases though.
This is way too intrusive a change to even think about just before
release. Please do this, though. Ship me a patch with three features:
1. Inserts the "give other devices a chance" code at what you think is
the right spot.
2. Includes a detailed comment explaining why the code is a good idea.
3. Important! The hole patch is wrapped with #ifdef __future__/#endif
That way I can apply it and we can study it in situ without committing
to use it in production code.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>