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> References: <201501042226.t04MQgfr085769@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>=20
> 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:
>=20
> 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=85 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?
>=20
> 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.
>=20
> 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.
>=20
>> I think we just need a "cork/uncork" sort of api that will make it a=20=
>> single line?
>=20
> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31BE601E-1D52-42FE-92FC-4610D0250A20>