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

socket peeking function #183

Open
daurnimator opened this issue Apr 19, 2017 · 0 comments
Open

socket peeking function #183

daurnimator opened this issue Apr 19, 2017 · 0 comments

Comments

@daurnimator
Copy link
Collaborator

From discussion back on 6th January (filing as issue now as I wanted to something public to refer to):

@wahern: it occurred to me that a good generic read interface would be pread. pread would be like a peek which accepted all the formats xread does, except it also could take an offset. and pread doesn't dequeue the data; that would be done manually (or through a special flag to pread).
@daurnimator: pread is already a posix-y function; bad name
@wahern: pread would also make it easier to build a peg-like parser around the interface.
@wahern: but the semantics would be almost identical.
@daurnimator: could have it as a flag to xread?
@daurnimator: precendent: recv() has MSG_PEEK.
@wahern: it's really messy to add to xread. a flag that signals another optional argument is even messier than it already is.
@wahern: but w'ever it's called, it could effectively replace the low-level recv call as the basic building block.
@daurnimator: sounds plausible
@daurnimator: would be good to see a prototype I guess
@wahern: it had it almost completely written at one point. in my head. the critical thing is that it makes speculative reads easy. no reading and putting back, or 0 timeouts, etc.
@daurnimator: it would also need to return the offset in the read buffer of where it was found
@daurnimator: (so that if you want to e.g. read a line followed by a length, you know where to start the length from)
@wahern: um. you provide the offset. but it would need to provide the trailing offset, so that the caller can discard and/or skip over the data when the returned string isn't the same length as the source string in the buffer (i.e. because of EOL translation).
@wahern: yeah. similar to what you said.

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

No branches or pull requests

1 participant