[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On July 18, 2011, Matthew Leverton wrote:
> This has been brought up a couple of times... same general concept
> here: allow a user to open up a subset of an already opened file. Its
> main use cases are:
>
> * loading a resource from within a custom data file of a known size
>
> * converting a sequential access file into a random access file
>
> It's not much different from the core memfile function, but it does
> let you work with a subset of a file without having to create a memory
> buffer (first use case), and in some cases, it feels more natural than
> manually creating a memfile.
>
> I've implemented the following as a file interface:
>
> ALLEGRO_FILE *al_fslice(ALLEGRO_FILE *fp, size_t initial_size, const
> char *mode);
> size_t al_get_fslice_size(ALLEGRO_FILE *fp);
> uint8_t *al_get_fslice_buffer(ALLEGRO_FILE *fp);
>
> I'm looking for feedback regarding the API and the general usefulness
> given its various restrictions.
>
> al_fslice() has the following modes that can be combined:
>
> r: read
> w: write
> a: append (implies write)
> m: memory buffer
>
> If buffered, then a buffer of initial_size is created (and owned by
> Allegro) and that amount of bytes are read from the file into the
> buffer. All read/write operations happen inside the memory buffer,
> which is expanded on write operations as needed. When flushed or
> closed, the data is written to the parent file.
>
> If not buffered, it's a wrapper over the underlying file, but the seek
> operations are relative and restricted to the inital size. All write
> operations are passed directly to the underlying system.
>
> When a slice is closed, the parent file handle's position is set to
> +initial_size.
>
> The various limitations, which shouldn't be surprising:
>
> * only one slice can be open per parent file at a time
> * the parent file must be kept open while the slice is in use
> * the parent file cannot be used while the slice is in use (unless
> it's buffered, read-only)
> * the slice mode must be sensible given the parent's mode. e.g.,
> Opening the child for in-place write, but with a parent that is
> append-write will give undefined behavior.
Hm, why? The all append does is start the file pointer at the end of the file,
nothing else changes. Since you can't give the start point for the fslice, the
slice would just start at the end of the file. If the user doesn't want that,
well they should either seek to where they want the slice, or not open it in
append mode.
> * write operations do not honor the file size limitations. If in-place
> writes go outside the initial size, anything past that slice will be
> overwritten. Append writes will always be placed at the end of the
> physical file. (It might make sense to optionally make in-place writes
> be constrained to the initial size.)
Maybe there should be an option to clamp writes to the size? I can see the use
for expanding writes, but it also might be useful to have fixed slice sizes.
> It could just be part of the memfile addon, as it provides similar
> functionality.
I really don't care where it goes, if fsclice essentially implements the same
feature, might as well just replace it. or emulate it.
> Or another option could be: 1) remove the buffered option from file
> slices and make it a core function and 2) add expandable memfiles into
> the memfile addon.
fslices do seem more useful than plain old memfiles, even expandable memfiles.
The memfile addon was really just a demo of the hooks, so people could see how
it was used, and so there was more than one implementation of the hooks
interface.
> --
> Matthew Leverton
>
> ---------------------------------------------------------------------------
> --- Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx