Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Request at least N bytes of space in buffers #103

Open
jakobnissen opened this issue Aug 17, 2020 · 2 comments
Open

Enhancement: Request at least N bytes of space in buffers #103

jakobnissen opened this issue Aug 17, 2020 · 2 comments

Comments

@jakobnissen
Copy link
Collaborator

A new codec is implemented by extending the process function, which gives you a number of input bytes to transcode, and a number of bytes to write the result to. Right now, there is, as far as I can see, no way of requesting at least N bytes of input/output space. This makes it a little annoying to implement blocked codexes.

E.g. in the following example:

julia> open("/tmp/file", "w") do file
           write(file, rand(UInt8, Int(1.5 * 1 << 17)))
       end
196608

julia> stream = NoopStream(open("/tmp/file"); bufsize=1<<18)
TranscodingStream{Noop,IOStream}(<mode=idle>)

julia> read(stream, UInt8); bytesavailable(stream)
131071

Here, even though the stream has 2^18 bytes of buffer, and the file is 1.5*2^17, only 2^17 bytes is read into the buffer at a time.

What assumptions can we make about the number of available bytes? Could we, somehow, force the codec to make at least N bytes available, unless we read the EOF?

@jakobnissen
Copy link
Collaborator Author

For future reference, the internal function makemargin!(::Buffer, N) will resize the buffer so that at least N bytes from the margin (that is, the end of the usable data) to the end of the buffer. It will not resize if there is already that much space, and will move away unmarked and used up data to make room before resizing.

This is purely internal, so not really safe for use. Still, useful to know.

@warrenalphonso
Copy link

warrenalphonso commented Oct 13, 2022

Was this fixed? I'm not so sure it's a problem.

If I set eager=true in fillbuffer, bytesavailable says I've processed the full 1.5*2^17 bytes. Without eager set, eof(stream.stream); bytesavailable(stream.stream) gave me 32768, which matched read(stream, UInt8); bytesavailable(stream). So I think this is limited by the input stream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants