Re: extended streams

[Eric Blake]

On 04/24/2010 05:00 AM, Bruno Haible wrote:
> These include AIX, HP-UX, IRIX, OSF/1, Solaris, mingw!
> 
>> the simplest thing we could think  
>> of is to create a temporary file under the hood, then provide gnulib
>> overrides of fflush and fclose (the only two points at which POSIX
>> requires that the original arguments to open_memstream are in sync
>> with what has happened to the stream).
> 
> Such an implementation would be gross. open_memstream can be used for
> light-weight operations like an extended sprintf with bells and whistles,
> or for building a HTTP response in memory. If you provide an implementation
> that does file system accesses and is therefore orders of magnitude slower
> than expected, you could as well leave open_memstream undefined in gnulib.

Well, maybe the fact that it is an order of implementation slower will
encourage: 1) upstream platforms to start complying with POSIX 2008 and
provide a working and efficient open_memstream, and 2) spur someone on
to further optimize the situation.  But in computer science, it's often
better to get something working and then work on optimization, than to
wait for the optimal solution with nothing in the meantime.

> Will string streams really be the only kind of non-file stream that you need
> in libvirt? Are you sure you will never need to do additional processing on
> the strings? Are you sure the amount of data is small enough that it is OK
> to store it in memory?

The decision of whether to use open_memstream vs. customized and fully
flexible streams is independent of whether open_memstream can at least
be implemented.  Yes, it might be better for libvirt to switch over to a
more powerful notion than what FILE* and stdio provides, if we are
concerned about efficiency.  But that is a much more invasive change,
and needs a lot of thought; whereas implementing open_memstream is
minimally invasive (even if it penalizes non-glibc platforms with puny
stdio implementations).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature