Re: [gpsd-dev] PPS and privilege-dropping

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> But that is the bug, you can not have a JSON emitter in the PPS thread!

I've fixed the problem.  The right thing to do is to put a mutex
exclusion around the one socket send(2) that's used for all JSON
writes to clients; the function is throttled_write() in gpsd.c.  Now,
no matter how control arrives there, no two of those sends while be
able to fire at once.  No more garbled output.

The really annoying thing is that I had done this before and it
worked.  Then I forgot why there was an exclusion around the send, and
*removed* it.

/me facepalms

Thankfully this was after 3.9, so the bad code never shipped for 
production.

> > The content of the report is a different issue.  You have implied
> > that the data in it is misleading; I want to know why you think that
> > and, if required, fix it.  (See "representation of domain" below.)
> 
> It is not using the right time structures.  I'll fix it.

OK.

> > That's not enough by itself.  You and other time nuts have implicit
> > knowledge, expressed in jargon like "chimers" which isn't actually
> > defined anywhere (I googled to check).  We need to get that knowledge
> > onto (virtual) paper.
> 
> Odd, I can't find a trvial reference to that either.  A chimer is just
> an time source you are using.  Likely remote in some 

You said something I found full of implications: "Basically you get several
good chimers and adjust fudges until they all agree."

I have a feeling that if I really understood that I would grok the
whole tuning process.  Can you unpack that into a paragraph, focusing
on how you *tell* when your chimers agree?

It sounds like a "fudge" is your estimate of the propagation delay
from the chimer, is that right?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature