On Thu, Sep 04, 2008 at 12:57:39PM +0200, Florian Forster wrote:
> > * forward declarations in the relevant *.c files
> > * internal-only include file
> > * change rrd_flush to a no-op if no daemon connection
>
> I'd use the second option. AfaIk `rrd_tool.h' is already such an
> internal-only file..
We came to the same conclusion independently.
> As far as I know, one of the goals for 1.4 is to imiprove the library to
> provide a ``real'' API, something very similar to the existing `*_r'
> functions. This means, of course, that some backwards-incompatible
> changes have to be made, but it might also be possible to provide a
> compatibility layer..
> [...]
> I think it's time for the old API to die. I see two big drawbacks to
> passing `argc' and `argv' to API functions:
I'll defer to Tobi on design changes of this magnitude.
> > * if the rate is too low, then client applications may block for a long
> > time waiting for flushes, while the hardware is idle (think graph with
> > a lot of RRDs).
>
> No, `flush' command don't honor the rate limit. It's a flush, not a case
> of ``Would be nice to have on disk again, in case of something goes
> wrong. Don't really care when this happens, though. Thanks.''
How do you propose implementing the rate lmit?
BTW I ran into an interesting bug that only appears under load.. the
sread() function doesn't handle this type of read well:
first read "UPDATE file 1:2:3:4\nUPDATE"
second read "FILE file2 3:4:5:6\n"
I think it would be best to consolidate the sread/swrite functions into a
single implementation that handles this case correctly.
Also, I am noticing that there are a few polling cycles that end up
installing NaN into my RRDs.. Have you run across this before? I'm
instrumenting some more debugging code to track this down now :/
--
kevin brintnall =~ /[EMAIL PROTECTED]/
_______________________________________________
rrd-developers mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
