(whoops. didn't go to list) > it would be cleaner and more maintainable to design it in two layers. Others > have disagreed with me on this before though.
My one gripe with this, and it was exposed in your email on c->rust mapping, is that you end up defining various libuv data structures in rust (including stuff defined in UV_HANDLE_PRIVATE_FIELDS), which strikes me as brittle, from a long-term maint. perspective. An elegant solution to address this doesn't really occur to me (header file/#define parsing in rustc?). Also, there are a number of unsafe operations we have to do in terms of managing data in the handles for their lifetime (kernel mallocs and frees). They'll be unsafe:: operations in rust, or the usual malloc/frees in C. There's no way around the pain, atm. So it isn't like hewing to rust gets us anything, here. In related news, my work on a proposal for libuv bindings is nearing a point where I can hopefully put forward a pull-request later today or tomorrow. It is by no means a complete mapping, but the patterns are in place and I'm reasonably happy with how it turned out. It's completely async, threadsafe, and retains the "character" of the C libuv api while leveraging the useful language opportunities that rust puts forward. Cheers, Jeff On Sun, Feb 19, 2012 at 7:26 PM, Brian Anderson <[email protected]> wrote: > ----- Original Message ----- >> From: "Zack Corr" <[email protected]> >> To: "Graydon Hoare" <[email protected]> >> Cc: [email protected] >> Sent: Sunday, February 19, 2012 5:42:49 PM >> Subject: Re: [rust-dev] Why exactly do we need low-level libuv bindings? >> >> This makes sense. I would be willing to help on the libuv bindings >> front, but let me get this straight before I go any further. An >> ideal setup of the low-level/high-level system would look like this: >> >> std::uv - low-level bindings to the libuv C API. >> std::event/std::ev - high-level bindings to the event loop part >> (timers and such) of std::uv. >> std::fs - high-level bindings to fs functions of std::uv as well as >> other filesystem functions. >> std::net - high-level bindings to the networking parts of std::uv as >> well as other networking functions. > > Possibly. I honestly haven't given much thought to what happens after we have > the libuv bindings. As you suggest though, the libuv API itself is not very > Rustlike, so maybe it does make sense to have another intermediate module, so > > std::uv::raw - Literally the C API exposed to Rust with all the struct > redefinitions, etc. that entails > std::uv - A friendlier API along the lines you suggested > > Beyond that possibly the module layout you suggest makes sense. It's still a > ways off and there's a lot of experimenting to do yet. Things that I imagine > we will want to build off of uv include: > > * async network I/O > * syncronous network I/O - With our task model we will have the luxury of > presenting a synchronous API that is built around the asynchronous API. It > will block individual tasks, but not any threads. > * async file I/O & sync file I/O > * timers - This is honestly the thing I want the most right now. There is > literally no way to sleep for a specified duration in Rust. > * we will also want to structure things, I think, so that by default all > these API's use some default event loop (which we have no mechanism to create > yet), but can also be used with a supplied event loop. I've heard opposition > to this idea though since it requires global state. > > Probably all of this stuff will be promoted to core eventually. > > fzzzy and I have been dabbling with libuv recently, and pfox has been trying > to clean up the existing uv code this week. More hands would be welcome and I > recommend stopping by IRC during work hours Pacific time to discuss plans. > >> P.S.S. I would suggest that std::net IPv6 parsing and formatting uses >> the libuv wrapper for this, because IPv6 addresses are very >> complicated and using a low-level function for it that handles the >> many shortcuts in the addresses would work better. > > Agreed that anything that uv supplies we should attempt to reuse. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
