tester for gpsd fixes

[Jussi Kukkonen]

Bernd Zeimetz wrote:
>> I originally used gps_set_callback() because in my opinion client
>> polling is a stupid idea here: gpsd is the one who knows when there is
>> data, we don't. I'm not an expert though, so I'm fine with changing that
>> if it's the way things are supposed to be done. It's just that seeing
>> g_timeout_add() used in a situation that doesn't seem to require either
>> polling or sub-second resolution, bugs me.
> 
> The callback was removed (for good) as clients are supposed to do their own
> thread handling now. It is save to span a thread and ask gpsd for data, but that
> will block until there is data. The other option is to open the connection in a
> non-blocking mode (which I've chosen, mainly because I don't really know how to
> handle threads and stuff with glib, never worked with it...) and just poll to
> see if there is data. It might make sense to use blocking mode in a thread, at
> least if you want to know about new data asap, withough waiting until the gpsd
> is being polled the next time.

It's not the wait I dislike (although that is an additional minus here), 
it's the unnecessary polling.

The thread implementation should be fairly easy (although not as easy as 
using library that supports events): have your blocking thread use 
g_idle_add () to start the actual event handler in main thread.

It's possible to use mutexes to make sure threads don't mess with the 
position data. Personally I'd just be lazy and allocate new position 
data in blocking thread and free it in the idle event handler in main 
thread, but I've heard that's not approved of in some circles :)

  - Jussi