X-Git-Url: http://mj.ucw.cz/gitweb/?a=blobdiff_plain;ds=sidebyside;f=ucw%2Ffastbuf.h;h=2c1c1a10aca2c693119b9e2aadf58122638ca45d;hb=f5bc3454ff581d0966e8b7384f41d67582264cb3;hp=c265fdb71235d3fa6481b6cd4720742b27c5977c;hpb=6e8db049cfa14313e9c20285b73e5b11f63201d1;p=libucw.git diff --git a/ucw/fastbuf.h b/ucw/fastbuf.h index c265fdb7..2c1c1a10 100644 --- a/ucw/fastbuf.h +++ b/ucw/fastbuf.h @@ -19,52 +19,108 @@ * * Generally speaking, a fastbuf consists of a buffer and a set of callbacks. * All front-end functions operate on the buffer and if the buffer becomes - * empty or fills up, they ask the corresponding callback to solve the + * empty or fills up, they ask the corresponding callback to handle the * situation. Back-ends then differ just in the definition of the callbacks. - * The state of the fastbuf is represented by `struct fastbuf`, which - * is a simple structure describing the state of the buffer and pointers - * to the callback functions. - * - * When we are reading from the fastbuf, the buffer is laid out as follows: - * - * +----------------+---------------------------+ - * | read data | free space | - * +----------------+---------------------------+ - * ^ ^ ^ ^ - * buffer bptr bstop bufend - * - * Here `bptr` points to the next character to be read. After the last character is - * read, `bptr == bstop` and the `refill` callback gets called upon the next read - * attempt to bring further data. This gives us an easy way how to implement @bungetc(). - * - * When writing, the situation looks like: - * - * +--------+--------------+--------------------+ - * | unused | written data | free space | - * +--------+--------------+--------------------+ - * ^ ^ ^ ^ - * buffer bstop bptr bufend - * - * In this case, the `bptr` points at the position where the next character - * will be written to. When we want to write, but `bptr == bufend`, we call - * the `spout` hook to flush the data and get an empty buffer. - * - * Several dirty tricks can be played: - * - * - The `spout`/`refill` hooks can change not only `bptr` and `bstop`, but also - * the location and size of the buffer; the fb-mem back-end takes advantage of it. - * - In some cases, the user of the `bdirect` interface can be allowed to modify - * the data in the buffer to avoid unnecessary copying. If the back-end - * allows such modifications, it can set `fastbuf->can_overwrite_buffer` accordingly: - * * 0 if no modification is allowed, - * * 1 if the user can modify the buffer on the condition that - * the modifications will be undone before calling the next - * fastbuf operation - * * 2 if the user is allowed to overwrite the data in the buffer - * if @bdirect_read_commit_modified() is called afterwards. - * In this case, the back-end must be prepared for trimming - * of the buffer which is done by the commit function. * + * The state of the fastbuf is represented by a <>, + * which is a simple structure describing the state of the buffer (the pointers + * `buffer`, `bufend`), the front-end cursor (`bptr`), the back-end cursor (`bstop`), + * position of the back-end cursor in the file (`pos`), some flags (`flags`) + * and pointers to the callback functions. + * + * The buffer can be in one of the following states: + * + * 1. Flushed: + * + * +------------------------------------+---------------------------+ + * | unused | free space | + * +------------------------------------+---------------------------+ + * ^ ^ ^ ^ + * buffer <= bstop (BE pos) <= bptr (FE pos) <= bufend + * + * * This schema describes a fastbuf after its initialization or bflush(). + * * There is no cached data and we are ready for any read or write operation + * (well, only if the back-end supports it). + * * The interval `[bptr, bufend]` can be used by front-ends + * for writing. If it is empty, the `spout` callback gets called + * upon the first write attempt to allocate a new buffer. Otherwise + * the fastbuf silently comes to the writing mode. + * * When a front-end needs to read something, it calls the `refill` callback. + * * The pointers can be either all non-`NULL` or all NULL. + * * `bstop == bptr` in most back-ends, but it is not necessary. Some + * in-memory streams take advantage of this. + * + * 2. Reading: + * + * +------------------------------------+---------------------------+ + * | read data | unused | + * +------------------------------------+---------------------------+ + * ^ ^ ^ ^ + * buffer <= bptr (FE pos) <= bstop (BE pos) <= bufend + * + * * If we try to read something, we get to the reading mode. + * * No writing is allowed until a flush operation. But note that @bflush() + * will simply set `bptr` to `bstop` before `spout` + * and it breaks the position of the front-end's cursor, + * so the user should seek afwards. + * * The interval `[buffer, bstop]` contains a block of data read by the back-end. + * `bptr` is the front-end's cursor which points to the next character to be read. + * After the last character is read, `bptr == bstop` and the `refill` callback + * gets called upon the next read attempt to bring further data. + * This gives us an easy way how to implement @bungetc(). + * + * 3. Writing: + * + * +-----------------------+----------------+-----------------------+ + * | unused | written data | free space | + * +-----------------------+----------------+-----------------------+ + * ^ ^ ^ ^ + * buffer <= bstop (BE pos) < bptr (FE pos) <= bufend + * + * * This schema corresponds to the situation after a write attempt. + * * No reading is allowed until a flush operation. + * * The `bptr` points at the position where the next character + * will be written to. When we want to write, but `bptr == bufend`, we call + * the `spout` hook to flush the witten data and get an empty buffer. + * * `bstop` usually points at the beginning of the written data, + * but it is not necessary. + * + * + * Rules for back-ends: + * + * - Front-ends are only allowed to change the value of `bptr`, some flags + * and if a fatal error occurs, then also `bstop`. Back-ends can rely on it. + * - `buffer <= bstop <= bufend` and `buffer <= bptr <= bufend`. + * - `pos` should be the real position in the file corresponding to the location of `bstop` in the buffer. + * It can be modified by any back-end's callback, but the position of `bptr` (`pos + (bptr - bstop)`) + * must stay unchanged after `refill` or `spout`. + * - Failed callbacks (except `close`) should use @bthrow(). + * - Any callback pointer may be NULL in case the callback is not implemented. + * - Callbacks can change not only `bptr` and `bstop`, but also the location and size of the buffer; + * the fb-mem back-end takes advantage of it. + * + * - Initialization: + * * out: `buffer <= bstop <= bptr <= bufend` (flushed). + * + * - `refill`: + * * in: `buffer <= bstop <= bptr <= bufend` (reading or flushed). + * * out: `buffer <= bptr <= bstop <= bufend` (reading). + * * Resulting `bptr == bstop` signals the end of file. + * The next reading attempt will again call `refill` which can succeed this time. + * * The callback must also return zero on EOF (iff `bptr == bstop`). + * + * - `spout`: + * * in: `buffer <= bstop <= bptr <= bufend` (writing or flushed). + * * out: `buffer <= bstop <= bptr < bufend` (flushed). + * + * - `seek`: + * * in: `buffer <= bstop <= bptr <= bufend` (flushed). + * * in: `(ofs >= 0 && whence == SEEK_SET) || (ofs <= 0 && whence == SEEK_END)`. + * * out: `buffer <= bstop <= bptr <= bufend` (flushed). + * + * - `close`: + * * in: `buffer <= bstop <= bptr <= bufend` (flushed or after @bthrow()). + * * `close` must always free all internal structures, even when it throws an exception. ***/ /** @@ -117,7 +173,7 @@ struct fb_params { }; struct cf_section; -extern struct cf_section fbpar_cf; /** Configuration section with which you can fill the `fb_params` **/ +extern struct cf_section fbpar_cf; /** Configuration section with which you can fill the `fb_params` **/ extern struct fb_params fbpar_def; /** The default `fb_params` **/ /** @@ -223,9 +279,11 @@ void bfix_tmp_file(struct fastbuf *fb, const char *name); struct fastbuf *bfdopen_internal(int fd, const char *name, uns buflen); struct fastbuf *bfmmopen_internal(int fd, const char *name, uns mode); +#ifdef CONFIG_UCW_FB_DIRECT extern uns fbdir_cheat; struct asio_queue; struct fastbuf *fbdir_open_fd_internal(int fd, const char *name, struct asio_queue *io_queue, uns buffer_size, uns read_ahead, uns write_back); +#endif void bclose_file_helper(struct fastbuf *f, int fd, int is_temp_file); @@ -444,12 +502,12 @@ static inline void bputc(struct fastbuf *f, uns c) /** Write a single character bputc_slow(f, c); } -static inline uns bavailr(struct fastbuf *f) +static inline uns bavailr(struct fastbuf *f) /** Return the length of the cached data to be read. Do not use directly. **/ { return f->bstop - f->bptr; } -static inline uns bavailw(struct fastbuf *f) +static inline uns bavailw(struct fastbuf *f) /** Return the length of the buffer available for writing. Do not use directly. **/ { return f->bufend - f->bptr; } @@ -568,7 +626,7 @@ static inline void bputsn(struct fastbuf *f, const char *b) void bbcopy_slow(struct fastbuf *f, struct fastbuf *t, uns l); /** * Copy @l bytes of data from fastbuf @f to fastbuf @t. - * `~0U` means all data, even if more than `~0U` bytes remain. + * `UINT_MAX` (`~0U`) means all data, even if more than `UINT_MAX` bytes remain. **/ static inline void bbcopy(struct fastbuf *f, struct fastbuf *t, uns l) { @@ -595,10 +653,28 @@ static inline int bskip(struct fastbuf *f, uns len) /** Skip @len bytes without } /*** === Direct I/O on buffers ***/ -// TODO Documentation -- what do they do? -static inline uns -bdirect_read_prepare(struct fastbuf *f, byte **buf) +/** + * Begin direct reading from fastbuf's internal buffer to avoid unnecessary copying. + * The function returns a buffer @buf together with its length in bytes (zero means EOF) + * with cached data to be read. + * + * Some back-ends allow the user to modify the data in the returned buffer to avoid unnecessary. + * If the back-end allows such modifications, it can set `f->can_overwrite_buffer` accordingly: + * + * - 0 if no modification is allowed, + * - 1 if the user can modify the buffer on the condition that + * the modifications will be undone before calling the next + * fastbuf operation + * - 2 if the user is allowed to overwrite the data in the buffer + * if @bdirect_read_commit_modified() is called afterwards. + * In this case, the back-end must be prepared for trimming + * of the buffer which is done by the commit function. + * + * The reading must be ended by @bdirect_read_commit() or @bdirect_read_commit_modified(), + * unless the user did not read or modify anything. + **/ +static inline uns bdirect_read_prepare(struct fastbuf *f, byte **buf) { if (f->bptr == f->bstop && !f->refill(f)) { @@ -609,21 +685,33 @@ bdirect_read_prepare(struct fastbuf *f, byte **buf) return bavailr(f); } -static inline void -bdirect_read_commit(struct fastbuf *f, byte *pos) +/** + * End direct reading started by @bdirect_read_prepare() and move the cursor at @pos. + * Data in the returned buffer must be same as after @bdirect_read_prepare() and + * @pos must point somewhere inside the buffer. + **/ +static inline void bdirect_read_commit(struct fastbuf *f, byte *pos) { f->bptr = pos; } -static inline void -bdirect_read_commit_modified(struct fastbuf *f, byte *pos) +/** + * Similar to @bdirect_read_commit(), but accepts also modified data before @pos. + * Note that such modifications are supported only if `f->can_overwrite_buffer == 2`. + **/ +static inline void bdirect_read_commit_modified(struct fastbuf *f, byte *pos) { f->bptr = pos; f->buffer = pos; /* Avoid seeking backwards in the buffer */ } -static inline uns -bdirect_write_prepare(struct fastbuf *f, byte **buf) +/** + * Start direct writing to fastbuf's internal buffer to avoid copy overhead. + * The function returns the length of the buffer in @buf (at least one byte) + * where we can write to. The operation must be ended by @bdirect_write_commit(), + * unless nothing is written. + **/ +static inline uns bdirect_write_prepare(struct fastbuf *f, byte **buf) { if (f->bptr == f->bufend) f->spout(f); @@ -631,8 +719,12 @@ bdirect_write_prepare(struct fastbuf *f, byte **buf) return bavailw(f); } -static inline void -bdirect_write_commit(struct fastbuf *f, byte *pos) +/** + * Commit the data written to the buffer returned by @bdirect_write_prepare(). + * The length is specified by @pos which must point just after the written data. + * Also moves the cursor to @pos. + **/ +static inline void bdirect_write_commit(struct fastbuf *f, byte *pos) { f->bptr = pos; }