Re: [gpsd-dev] Minimum working example for libgps

[Hal Murray]

address@hidden said:
>> A "main loop" makes sense if you have a typical GUI program.
> Or any long lasting program.  The program has to be looping/sleeping
> somewhere to be ready for callbacks, user input, or gpsd input. 

I think your "any" is only valid for a subset of interesting programs.  Yes, 
it's a large subset.

Consider a main loop that gets input from X, Y, and Z.  What are the 
constraints needed to make a main loop work?

If all the APIs have a poll option, you can sleep for a short time when all 
have no input.

If one API has a timeout, you can wait there yet get back often enough to 
poll the others.

Or something like that.


> I'll bet he does have a loop, he has to be waiting somewhere for the thread
> to get back to him.  Adding another thread is just an overcomplication.

In a thread friendly environment, that code is pretty simple.  Yes, it's more 
work if you don't have any threads yet.

> Wherever he is sitting, waaiting for work, that is a loop.  Just poll gpsd
> in there. 

If you have a multi-threaded program, none of the read/do loops may be the 
main one.  Consider a server with one thread per client.

An alternate way of looking at things is that the OP doesn't like the API 
that gpsd provides.  The gpsd model is that it gives you all the data it gets 
and you have to pull often enough to keep the buffer from clogging.  An 
alternative model is that it digests everything, saves the latest values, and 
you can call in (no blocking) and get the latest/current value of X.

Many years ago, I was on the fringe of various API wars.  Should the API be 
push, callback, pull, or...?  We got pretty good at writing tiny adapter 
modules.  They are simple in a thread friendly environment.  I think the 
common case was a buffer, a thread, and less than a page of code.





-- 
These are my opinions.  I hate spam.