Date: Sun, 4 Jan 2015 16:08:13 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Phil Shafer <phil@juniper.net> Cc: Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, "arch@freebsd.org" <arch@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch <freebsd-arch@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: Libxo bugs and fixes. Message-ID: <31BE601E-1D52-42FE-92FC-4610D0250A20@freebsd.org> In-Reply-To: <201501042226.t04MQgfr085769@idle.juniper.net>
index | next in thread | previous in thread | raw e-mail
On Jan 4, 2015, at 2:26 PM, Phil Shafer wrote:
> Alfred Perlstein writes:
>> On 1/3/15 9:05 PM, Phil Shafer wrote:
>>> I dislike using a non-standard function like this. I'd prefer the
>>> caller flag this information on the handle. There's already a flag
>>> one can set on a handle that will trigger a call to flush data
>>> buffered in the handle to the write function. I'll add a function
>>> to set a custom flusher, which will be called at appropriate times.
>>> Apps like netstat will know if they need iterative output, and can
>>> decide to set the XOF_FLUSH flag with a flusher callback. If needed,
>>> that callback can use __flbf.
>
> We considering this: given that the caller knows when it wants to
> fflush(stdout) and libxo doesn't, it seems we'd be better served
> having the app do something like:
>
> for (;;) {
> xo_open_instance("foo");
> ...
> xo_close_instance("foo");
> xo_flush(); /* Flush data buffersd in libxo */
> if (__flbf(stdout))
> fflush(stdout); /* Flush data buffered in stdio */
> }
That api… could it not be better? Also, won't it be fully buffered when it's to a pipe to another program? I think I messed that up. We probably want actually if !__flbf() I think which for non-buffered will cause a nop-fflush but for fully buffered will do an actual flush.
I think we REALLY want to have the fflush be a callback offered by libxo, otherwise the layering violations are pretty difficult to deal with. Consider if libxo is outputting to a non-stdio buffer, then what is the paradigm? Is it not better to give libxo a "flush" callback and have that exposed via the xop interface?
>
> xo_flush flushes the data that libxo is buffering in the handle,
> which is used to avoid making malformed XML and JSON content.
> Then fflush can push that data out if needed.
>
> The XOF_FLUSH flushes data after every call from the xo handle to
> the underlaying opaque stream; putting a flush at that point would
> likely be overkill.
>
>> I think we just need a "cork/uncork" sort of api that will make it a
>> single line?
>
> I can make a flag to push container and list names as they are opened,
> so a function can close, add an inter-record string (a NL for NLDJSON),
> and reopen the tags. Since I have the keys, I could add those also.
That sounds awesome.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31BE601E-1D52-42FE-92FC-4610D0250A20>