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.

Sign up for GitHub

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

Jump to bottom

Towards a pluggable EventLoop, etc #9128

Closed
olsonjeffery opened this issue Sep 11, 2013 · 4 comments
Closed

Towards a pluggable EventLoop, etc #9128

olsonjeffery opened this issue Sep 11, 2013 · 4 comments

Comments

@olsonjeffery
Copy link
Contributor

In no particular order:

  • fixing the ~objects
  • creating a BasicEventLoop implementation using standard mutexes and condition variables and converting some of the primitive Scheduler tests to use it
  • creating a runtime API for spawning the runtime and/or schedulers with a custom EventLoop
  • reviewing PausibleIdleCallback to determine if it's too uv-specific

would be nice to have another event loop (besides libuv) to use to flesh this out. Related to #4419
@toddaaro
Copy link
Contributor

I am very curious what a better design for the PausibleIdleCallback is. It is fairly quirky right now. It might be that a few minor tweaks combined with a rename to "ToggleableIdleBehavior" or something is sufficient.

@olsonjeffery
Copy link
Contributor Author

from IRC:

<@brson> olsonjeffery: i would have like to make all the tests in sched.rs not rely on libuv
<@brson> olsonjeffery: for a BasicEventLoop i would expose the 'signal' part of the C++ 'lock_and_signal' type,
           which is just a mutex + condition variable, and use that for simulating the libuv async handles

This was referenced Sep 25, 2013
Closed
Closed
@alexcrichton alexcrichton mentioned this issue Oct 18, 2013
Merged
bors added a commit that referenced this issue Oct 24, 2013
@bors
auto merge of #9901 : alexcrichton/rust/unix-sockets, r=brson
a5c00e8 
Large topics:

* Implemented `rt::io::net::unix`. We've got an implementation backed by "named pipes" for windows for free from libuv, so I'm not sure if these should be `cfg(unix)` or whether they'd be better placed in `rt::io::pipe` (which is currently kinda useless), or to leave in `unix`. Regardless, we probably shouldn't deny windows of functionality which it certainly has.
* Fully implemented `net::addrinfo`, or at least fully implemented in the sense of making the best attempt to wrap libuv's `getaddrinfo` api
* Moved standard I/O to a libuv TTY instead of just a plain old file descriptor. I found that this interacted better when closing stdin, and it has the added bonus of getting things like terminal dimentions (someone should make a progress bar now!)
* Migrate to `~Trait` instead of a typedef'd object where possible. There are only two more types which are blocked on this, and those are traits which have a method which takes by-value self (there's an open issue on this)
* Drop `rt::io::support::PathLike` in favor of just `ToCStr`. We recently had a lot of Path work done, but it still wasn't getting passed down to libuv (there was an intermediate string conversion), and this allows true paths to work all the way down to libuv (and anything else that can become a C string).
* Removes `extra::fileinput` and `extra::io_util`


Closes #9895 
Closes #9975
Closes #8330
Closes #6850 (ported lots of libraries away from std::io)
cc #4248 (implemented unix/dns)
cc #9128 (made everything truly trait objects)
@alexcrichton alexcrichton mentioned this issue Oct 24, 2013
Merged
bors added a commit that referenced this issue Oct 24, 2013
@bors
auto merge of #9901 : alexcrichton/rust/unix-sockets, r=brson
3f5b221 
Large topics:

* Implemented `rt::io::net::unix`. We've got an implementation backed by "named pipes" for windows for free from libuv, so I'm not sure if these should be `cfg(unix)` or whether they'd be better placed in `rt::io::pipe` (which is currently kinda useless), or to leave in `unix`. Regardless, we probably shouldn't deny windows of functionality which it certainly has.
* Fully implemented `net::addrinfo`, or at least fully implemented in the sense of making the best attempt to wrap libuv's `getaddrinfo` api
* Moved standard I/O to a libuv TTY instead of just a plain old file descriptor. I found that this interacted better when closing stdin, and it has the added bonus of getting things like terminal dimentions (someone should make a progress bar now!)
* Migrate to `~Trait` instead of a typedef'd object where possible. There are only two more types which are blocked on this, and those are traits which have a method which takes by-value self (there's an open issue on this)
* Drop `rt::io::support::PathLike` in favor of just `ToCStr`. We recently had a lot of Path work done, but it still wasn't getting passed down to libuv (there was an intermediate string conversion), and this allows true paths to work all the way down to libuv (and anything else that can become a C string).
* Removes `extra::fileinput` and `extra::io_util`


Closes #9895 
Closes #9975
Closes #8330
Closes #6850 (ported lots of libraries away from std::io)
cc #4248 (implemented unix/dns)
cc #9128 (made everything truly trait objects)
@alexcrichton alexcrichton mentioned this issue Oct 24, 2013
Merged
alexcrichton added a commit to alexcrichton/rust that referenced this issue Oct 25, 2013
@alexcrichton
Implement a basic event loop built on LittleLock
64a5c3b 
It's not guaranteed that there will always be an event loop to run, and this
implementation will serve as an incredibly basic one which does not provide any
I/O, but allows the scheduler to still run.

cc rust-lang#9128
bors added a commit that referenced this issue Oct 25, 2013
@bors
auto merge of #10054 : alexcrichton/rust/basic-event-loop, r=brson
deeca5d 
This is more progress towards #9128 and all its related tree of issues. This implements a new `BasicLoop` on top of pthreads synchronization primitives (wrapped in `LittleLock`). This also removes the wonky `callback_ms` function from the interface of the event loop.

After #9901 is taking forever to land, I'm going to try to do all this runtime work in much smaller chunks than before. Right now this will not work unless #9901 lands first, but I'm close to landing it (hopefully), and I wanted to go ahead and get this reviewed before throwing it at bors later on down the road.

This "pausible idle callback" is also a bit of a weird idea, but it wasn't as difficult to implement as callback_ms so I'm more semi-ok with it.
@alexcrichton
Copy link
Member

cc #5019

bors added a commit that referenced this issue Oct 29, 2013
@bors
auto merge of #10058 : alexcrichton/rust/uv-crate, r=brson
93cb9e7 
This is one of the final steps needed to complete #9128. It still needs a little bit of polish before closing that issue, but it's in a pretty much "done" state now.

The idea here is that the entire event loop implementation using libuv is now housed in `librustuv` as a completely separate library. This library is then injected (via `extern mod rustv`) into executable builds (similarly to how libstd is injected, tunable via `#[no_uv]`) to bring in the "rust blessed event loop implementation."

Codegen-wise, there is a new `event_loop_factory` language item which is tagged on a function with 0 arguments returning `~EventLoop`. This function's symbol is then inserted into the crate map for an executable crate, and if there is no definition of the `event_loop_factory` language item then the value is null.

What this means is that embedding rust as a library in another language just got a little harder. Libraries don't have crate maps, which means that there's no way to find the event loop implementation to spin up the runtime. That being said, it's always possible to build the runtime manually. This request also makes more runtime components public which should probably be public anyway. This new public-ness should allow custom scheduler setups everywhere regardless of whether you follow the `rt::start `path.
bors added a commit that referenced this issue Oct 29, 2013
@bors
auto merge of #10058 : alexcrichton/rust/uv-crate, r=brson
52f42f1 
This is one of the final steps needed to complete #9128. It still needs a little bit of polish before closing that issue, but it's in a pretty much "done" state now.

The idea here is that the entire event loop implementation using libuv is now housed in `librustuv` as a completely separate library. This library is then injected (via `extern mod rustv`) into executable builds (similarly to how libstd is injected, tunable via `#[no_uv]`) to bring in the "rust blessed event loop implementation."

Codegen-wise, there is a new `event_loop_factory` language item which is tagged on a function with 0 arguments returning `~EventLoop`. This function's symbol is then inserted into the crate map for an executable crate, and if there is no definition of the `event_loop_factory` language item then the value is null.

What this means is that embedding rust as a library in another language just got a little harder. Libraries don't have crate maps, which means that there's no way to find the event loop implementation to spin up the runtime. That being said, it's always possible to build the runtime manually. This request also makes more runtime components public which should probably be public anyway. This new public-ness should allow custom scheduler setups everywhere regardless of whether you follow the `rt::start `path.
@alexcrichton
Copy link
Member

This is now possible, implemented, working, and being tested. I don't believe that there's much left to do here.

We can evaluate the libuv-ness of things, but that's a separate bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@olsonjeffery @alexcrichton @toddaaro