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

provide control over transcoded-port buffer sizes #708

Merged
merged 5 commits into from
Aug 2, 2023

Conversation

owaddell
Copy link
Contributor

@owaddell owaddell commented Jul 25, 2023

This pull request adds two new parameters that provide control over the size of the string buffer and the internal codec bytevector buffer associated with transcoded ports. It also includes changes to reduce allocation and copying in certain cases for bytevector->string, get-bytevector-all, get-bytevector-n, get-string-all, and get-string-n.

One use case for the new parameters is to allow transcoded custom binary ports to take advantage of larger buffer sizes. Previously, such ports were effectively constrained by a fixed 1024-byte internal codec buffer even if created with a large custom-port-buffer-size.

Resolved questions:

  • Could / should we avoid allocating the ioffsets fxvector if the underlying bp does not support port-position? (Yes. Updated to avoid allocating ioffsets fxvector in this case.)
  • Should make-codec-buffer procedure take bp and min-size instead of just bp? (For now keeping bp as the only argument.)
    • con: For existing codecs it will always be 4, so why pass it in. (Perhaps it could be less for latin-1-codec, but that's seems pedantic.)
    • con: immediate 4 is compact in the code stream
    • con: if users know the minimum is 4 they could skip the check in cases where they know they have something of length >= 4 available.
    • pro: having a min-size argument is a reminder that there is in fact a minimum length
    • pro: avoids ugly occurrences of "four" in documentation and 4 in user code
  • Should I merge the two error checks on the result from make-codec-buffer into one? (Yes. Done.)

csug/io.stex Outdated Show resolved Hide resolved
mats/io.ms Outdated Show resolved Hide resolved
mats/io.ms Outdated Show resolved Hide resolved
@jltaylor-us
Copy link
Contributor

Looks good to me.

Use get-string-all in fresh-line mats where the expected result
from block-read relied on the input-port's buffer size.
The string-ports mat expects prettytest.ss to be ASCII. Unicode
characters in the files comprising prettysrc can break the test.
Add hint to help the next person who stumbles on this.

We could update the prettytest.ss make rule to convert the output to
ASCII, but that would add a build dependency on something like iconv.
We could do the conversion in Scheme, but that would rely on the system
under test.
Add transcoded-port-buffer-size to provide control over the string buffer
allocated for a new transcoded port. For transcoded input ports this also
governs the size of an internal fxvector used by port-position.

Add make-codec-buffer to allow control over the internal bytevector buffer
for a transcoded port.

Note that we get a few new "Expected error" cases for some io.ms mats
that were extended by adding new parameters clauses. The mat parameters
clause re-runs the mat body with different parameter settings. Here that
means we happen to repeat some tests that check expected errors.
Avoid extra allocation and copying when get-bytevector-all,
get-bytevector-n, get-string-all, and get-string-n can
construct the result from a single file-buffer-size block.
Allocate minimum-sized buffers for transcoded port and codec when the
bytevector argument is less than file-buffer-size. Avoid extra
allocation and copy of result in that case. Take advantage of shared
buffer if user has determined this is safe.
@owaddell
Copy link
Contributor Author

owaddell commented Aug 2, 2023

Thanks for the reviews, folks!

@owaddell owaddell merged commit 821879d into cisco:main Aug 2, 2023
20 checks passed
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

Successfully merging this pull request may close these issues.

4 participants