Re: [gpsd-dev] stuck in consume_packets/multipoll loop

[Eric S. Raymond]

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>