[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsd processor load

From: Chris Kuethe
Subject: Re: [gpsd-dev] gpsd processor load
Date: Wed, 30 Oct 2013 17:21:47 -0700

On Wed, Oct 30, 2013 at 4:30 PM, Gary E. Miller <address@hidden> wrote:
Yo Chris!

On Wed, 30 Oct 2013 16:16:24 -0700
Chris Kuethe <address@hidden> wrote:

> > TIOCMIWAIT is what sleeps and wakes up the thread.  It would need
> > to be replaced with some sort of usleep() and then KPPS would need
> > to actually work on BSD.  Doable, but a lot of work, and only a BSD
> > person could do it.
> I don't think any of the BSDs seem to have TIOCMIWAIT.

I baffled how they can manage without TIOCMIWAIT.  How can you write any
sort of low level serial client without it?  BSD has to have some way to
wake on control changes...

Not in the way pps needs. 

No mention of it

> I think select() will return a ready fd with no data bytes from
> read() when a control line changes.

Thn the PPS thread would wake up on every character as well.  Not good.


On OpenBSD one can make a call to activate control line timestamp recording on a tty another ioctl call to query the last timestamp. But that still means a wakeup-per-char, rather than blocking until just a control line toggles.

> Could we fake it on that?

Maybe, but it all needs KPPS to work to get any sort of time.  And if
KPPS is working we just need to wake up the thread a few times a second
and check if KPPS has anything for us.

And the interface we're using on linux doesn't exist on bsd.

Looking at RFC 2783, there is a way to have time_pps_fecth() block until
the next edge.  Linux does not need that and has no documentation if it
would work.  That might be the answer if you can figure it out.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

GDB has a 'break' feature; why doesn't it have 'fix' too?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]