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
_______________________________________________
GeoClue mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/geoclue
