[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-dev
Subject:    [Gpsd-dev] Considering a 2.27 point release
From:       esr () thyrsus ! com (Eric S !  Raymond)
Date:       2005-06-28 11:30:23
Message-ID: 20050628113023.GA477 () thyrsus ! com
[Download RAW message or body]

Rob Janssen <gpsd@xs4all.nl>:
> Well, at least the observed behaviour was that it was calling the FIONREAD
> ioctl in a loop and it returned 0 all the time.

If I ever knew this, I had forgotten it.  Yes, that sounds like the smoking 
gun.  Damn.  FIONREAD has always been a bit dodgy; I wasn't really happy 
about using it and I guess my misgivings were correct.

> There may be some problem with that ioctl.  I should say I never use it.
> It should be possible to use only select() and have the returned bitmask
> available.  When the bit corresponding to an fd is set we can make one
> read call of a reasonable size (to fill the input buffer) and then we
> should return to the select loop (after having tested all the bits in a
> row) to do a new select to see if more input is available.
> It is also possible to setup the serial port such a way that when read is
> called and no data is available the read just returns.

I went and stared at this code for a while, trying to think how to get
rid of the FIONREAD ioctl().  

is_input_waiting() gets used in two separate places, close together in
gpsd_poll.  One of them would be trivial to eliminate; we can just put
the DGPS correction socket in non-blocking mode, read from it, and see
how much we get.

Unfortunately, I'm almost sure it's the other one that's the problem.
If it were guarding an explict read, rearranging the logic to use a
non-blocking fd would be easy.  The problem is that it dives into
the packet_get method, which has a read() call buried inside it.

Ugh.  Inverting that logic is going to be ugly and no fun.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[prev in list] [next in list] [prev in thread] [next in thread]