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

Update or write rust bindings for libuv #25

Open
creationix opened this issue Jun 18, 2016 · 4 comments
Open

Update or write rust bindings for libuv #25

creationix opened this issue Jun 18, 2016 · 4 comments

Comments

@creationix
Copy link
Member

No description provided.

@Qard
Copy link

Qard commented Jun 23, 2016

I updated libuv-sys to support 1.9.1 just the other day. You could ask @sorear to push it up to crates.io. It still lacks a higher-level, Rust-friendly abstract API though.

@creationix
Copy link
Member Author

@Qard, thanks, that sounds useful.

I did have a question that you might know the answer. I'm considering a pure rust version of nucleus using rjs and the rust stblib instead of binding to libuv. Are there parts in the libuv API that would hard to simulate using rusts standard libraries and pure rust libs on crates.io?

@sorear
Copy link

sorear commented Jun 24, 2016

@creationix Rust has no multiplexed I/O facility in the standard library whatsoever. If you're doing Rust and avoiding FFI for whatever reason, you need one thread per open socket. This is why I started the UV binding in the first place, although the database server I was planning to write has languished for other reasons, so I never got around to writing the high-level UV interface. I think I was going to do a callback-based interface but handling ownership with Rc stuff, but it's a bit fuzzy. Also, microtasks (I found a way to do the moral equivalent of a Deque<Box<FnOnce()>> with no memory allocation, for a neat trick).

There are other Rust libraries (necessarily using FFI because the above) for doing multiplexed I/O, but at the time I scoped out the project they looked various combinations of immature and overengineered. Better to wrap something time-tested.

@creationix
Copy link
Member Author

@sorear thanks, that's helpful information.

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

3 participants