Hello Uwe,
> > Like I said, we know, pipes are not suited at all for the task. I must > > admit, I was not aware of the issue before, I was under impression, we > > could simply set stdin/stdout to no buffering, but it appears for pipes > > that is not an option, and thinking about it, pipes really need to > > buffer. > > MY guess is you don't know enough about unix(like) systems to build any > meaningfull software with the stringent requirements linked to your > applications environment. > You may want to read up on pipes, ptys and associated buffering. I have no idea what triggered this. > > We were considering to use an expect wrapper (python-expect) to channel > > the data to us, and it would certainly improve the results. But I see no > > reason to use that workaround at all. Why should we make ntpq draw ASCII > > art only to parse it and endure the changes between your releases? > > I personally don't release anything. I didn't say so. In German I would have said "Änderungen zwischen Euren Releases" and it would have been clear that I didn't mean you personally, of I did course not. In English it happens to be the same word, "your" for one person or a group, sorry if I was not clear enough. > > What we really want to do is to use libntp to send out some queries to > > the ntpd servers we monitor (10 of them) and async wait for replies to > > process them immediately and with minimal latency. > > > >>And you seem to work through your jobs in a serial way? Use select(). > > > > Well, yes of course. Short of using expect, we ran ntpq each time anew > > and fetched its response immediately. That was good enough for a > > prototype that re-used parsing code that we already have for ntpq output, > > but now we would like to do better. > > well parsing any output with expect is trivial. > I wonder why Eurocontrol is well served with tcl. And the point of it is what? I didn't say anything against tcl, nor would I, nor could I. It's a fine tool. But given the choice, we would prefer to use a libntp. What's wrong with that, except that you don't find it necessary? On the pro-side there is: a) A significant reduction in lines of code used which can only lead to less bugs. b) The CPU used to make one set of queries will be lower potentially enabling a higher frequency of checks achieving lower latency in detecting NTP problems. Best regards, Kay Hayen _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
