Skip site navigation (1)Skip section navigation (2)
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>