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

Newrt file io #8655

Closed
wants to merge 26 commits into from
Closed

Conversation

olsonjeffery
Copy link
Contributor

This PR includes the addition of the essential CRUD functionality exposed as a part of the uv_fs_* api. There's a lot more to be done, but the essential abstractions are in place and can be easily expanded.

A summary:

  • rt::io::file::FileStream is fleshed out and behaves as a non-positional file stream (that is, it has a cursor that can be viewed/changed via tell and seek
  • The underlying abstraction in RtioFileStream exposes pairs of read(), write() and pread(), pwrite(). The latter two take explicit offset params and don't respect the current cursor location in a file afaik. They both use the same underlying libuv impl
  • Because libuv explicitly does not support seek/tell operations, these are impl'd in UvFileStream by using lseek(2) on the raw file descriptor.
  • I did my best to flesh out and adhere to the stubbing that was already present in rt::io::file and the tests should back that up. There may be things missing.
  • All of the work to test seek/tell is done in rt::io::file, even though the actual impl is down in rt::uv::uvio.
  • We have the ability to spin up an ~RtioFileStream from a raw file descriptor. This would be useful for interacting with stdin and stdout via newrt.
  • The lowest level abstractions (in rt::uv::file) support fully synchronous/blocking interactions with the uv API and there is a CRUD test using it. This may also be useful for blocking printf, if desired (the default would be non-blocking and uses libuv's io threadpool)

There are a few polish things I need to do still (the foremost that I know of is undefined behavior when seek'ing beyond the file's boundary).

After this lands, I want to move on to mapping more of the uv_fs_* API (especially uv_fs_stat). Also a few people have mentioned interest in uv_pipe_t support. I'm open to suggestions.

@alexcrichton
Copy link
Member

For pipe support, I started adding a few basic capabilities for uv_pipe_t in #8645, although they're nowhere near complete. I basically added the bare-minimum to get pipes to child processes up and running. (just fyi)

@brson
Copy link
Contributor

brson commented Aug 21, 2013

@olsonjeffery This is really amazing. Thanks so much!

I think the main things to do here before merging are change the tmp files and fix the signal handling. The remaining design issues can be iterated on.

…ended

- change all uses of Path in fn args to &P
- FileStream.read assumptions were wrong (libuv file io is non-positional)
- the above will mean that we "own" Seek impl info .. should probably
  push it in UvFileDescriptor..
- needs more tests
bors added a commit that referenced this pull request Aug 23, 2013
This PR includes the addition of the essential CRUD functionality exposed as a part of the `uv_fs_*` api. There's a lot more to be done, but the essential abstractions are in place and can be easily expanded.

A summary:

* `rt::io::file::FileStream` is fleshed out and behaves as a *non-positional* file stream (that is, it has a cursor that can be viewed/changed via `tell` and `seek`
* The underlying abstraction in `RtioFileStream` exposes pairs of `read(), write()` and `pread(), pwrite()`. The latter two take explicit `offset` params and don't respect the current cursor location in a file afaik. They both use the same underlying libuv impl
* Because libuv explicitly does *not* support `seek`/`tell` operations, these are impl'd in `UvFileStream` by using `lseek(2)` on the raw file descriptor.
* I did my best to flesh out and adhere to the stubbing that was already present in `rt::io::file` and the tests should back that up. There may be things missing.
* All of the work to test `seek`/`tell` is done in `rt::io::file`, even though the actual impl is down in `rt::uv::uvio`.
* We have the ability to spin up an `~RtioFileStream` from a raw file descriptor. This would be useful for interacting with stdin and stdout via newrt.
* The lowest level abstractions (in `rt::uv::file`) support fully synchronous/blocking interactions with the uv API and there is a CRUD test using it. This may also be useful for blocking printf, if desired (the default would be non-blocking and uses libuv's io threadpool)

There are a few polish things I need to do still (the foremost that I know of is undefined behavior when seek'ing beyond the file's boundary).

After this lands, I want to move on to mapping more of the `uv_fs_*` API (especially `uv_fs_stat`). Also a few people have mentioned interest in `uv_pipe_t` support. I'm open to suggestions.
@bors bors closed this Aug 23, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 7, 2022
Allow raw lint descriptions

update_lints now understands raw strings in declare_clippy_lint descriptions.

Supersedes  rust-lang#8655

cc `@Alexendoo` thanks for addressing this so quickly. I build a little bit simpler version of your patch. I don't think it really matters what `Literal` we're trying to tokenize, since we assume later, that it is some sort of `str`.

changelog: none
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.

None yet

5 participants