From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 00:04:34 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB9DA7C; Mon, 5 Jan 2015 00:04:34 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1DA2A08; Mon, 5 Jan 2015 00:04:34 +0000 (UTC) Received: from [10.0.1.110] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 31A6F341F88A; Sun, 4 Jan 2015 16:04:28 -0800 (PST) Subject: Re: Libxo bugs and fixes. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alfred Perlstein In-Reply-To: <201501042226.t04MQgfr085769@idle.juniper.net> Date: Sun, 4 Jan 2015 16:08:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31BE601E-1D52-42FE-92FC-4610D0250A20@freebsd.org> References: <201501042226.t04MQgfr085769@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1283) Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 00:04:34 -0000 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.=