Date: Sun, 4 Jan 2015 16:52:26 -0800 From: Alfred Perlstein <bright@mu.org> To: Phil Shafer <phil@juniper.net> Cc: Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Alfred Perlstein <alfred@freebsd.org>, "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: <B2197911-9DA2-420B-AB17-0DCF09D35799@mu.org> In-Reply-To: <201501050033.t050X9L5086220@idle.juniper.net> References: <201501050033.t050X9L5086220@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 4, 2015, at 4:33 PM, Phil Shafer <phil@juniper.net> wrote: >=20 > Alfred Perlstein writes: >> I think we REALLY want to have the fflush be a callback offered by libxo,= otherwise the=20 >> layering violations are pretty difficult to deal with. Consider if libxo= is outputting=20 >> to a non-stdio buffer, then what is the paradigm? Is it not better to gi= ve libxo a "flu >> sh" callback and have that exposed via the xop interface? >=20 > The problem is divining when to flush. If you are whiffling thru a list, > does the app want to flush after each list member, or when the complete > list is done. >=20 > Or maybe you are just looking at the case when pretty output > is made to the terminal? I am more thinking of the case where you pass a libxo handle down to a subsy= stem that shouldn't have to know if it is a studio object or not.=20 Consider the code sample you gave me, but instead of using the handleless ve= rsion xo_flush() you are writing a routine that takes a handle so instead yo= u would be calling xo_flush_h().=20 In the case of xo_flush_h() how does a subroutine know how to flush the back= ing object of the handle? -ap=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2197911-9DA2-420B-AB17-0DCF09D35799>