Evaluate using coroutine::Context instead of coroutine::Coroutine. Maybe there are some gains by not using global scheduling etc.

[dpc]

Evaluate using coroutine::Context instead of coroutine::Coroutine. Maybe there are some gains by not using global scheduling etc.

[zonyitoo]

I am planning on refactor the coroutine-rs library to work just like coroutine in Boost. That would provide more flexible APIs for you to define what user could do in your callback function.

[dpc]

I don't know how boost one works, but what we need in essence is really a context state for each handler ability to switch to it and and get back. Alternatively an exposed scheduler API. So I can have one scheduler for each mioco server instance, and potentially user being able to use coroutines withing handlers, but without interfering with a mioco server scheduler state.

[zonyitoo]

Maybe you can put the Scheduler into a thread local structure.

a context state for each handler ability to switch to it and and get back

I think this is in the feature clonable-handler.

[dpc]

I thought clonable handler just gives me an ability to clone Closure handler. Which I already use.

I want to have more Schedulers on the same thread.

[zonyitoo]

I don't know what exactly you want. Maybe I should look deep into your source code.

[dpc]

I don't think source will tell much. It's just, I would like to it to be possible to have a scheduler state that cannot be interfered from outside.

In mioco we have server, that is scheduling coroutines (handlers). It depends on coroutine_handle.resume() jumping into handler, and coroutine::block() in the handler to get back to server. If handlers code will start using coroutines on it's own, then there might be more runnable coroutines and then it all falls appart: eg. block() will not get back to the server code, but instead resume some other coroutine that did yield() before or something similar.

[zonyitoo]

Ok, I see. So you want to have a scheduler. Maybe you could redefine the spawn function to restrict those new spawned coroutines to be managed inside the scheduler.

On the other hand, you could also reverse your architecture, which means that a server just one of the coroutines that running on the scheduler. I think you may be interested in this repo: https://github.com/zonyitoo/simplesched

[dpc]

If I'm to work on this, I think I'm just going to get a context switch functionality.

[zonyitoo]

So, maybe I should expose the context API?

[dpc]

That would be awesome. I've been looking into https://github.com/rustcc/coroutine-rs/blob/master/src/context.rs on how to plug mioco to it, but that's it.

[zonyitoo]

Please try to use this crate: https://github.com/zonyitoo/context-rs
Happy hacking :)

[dpc]

Awesome! Thanks!

[dpc]

context-rs was exactly what I needed!

[zonyitoo]

You may try the feature-fnbox branch.

[dpc]

@zonyitoo : What's the difference? What does it give me? :) . I see that "Send" from initfn is gone.

You want me to try to see if it works OK?

[zonyitoo]

This version uses the latest feature FnBox in the libstd. So I can get rid of the Thunk and Send trait.

Please try whether it works Ok, I want to merge it into the master branch.

[dpc]

Any reason you use internal libc? I thought we're supposed to use crates.io version, no?

[zonyitoo]

Just for historical reason, let me make some updates.

[dpc]

Ready. Branch context-feature-fnbox. It works here. I like the fact that I don't have to fake Send now. But the additional feature-s will prevent us from working on anything but nightly for a while.

[dpc]

I can merge it as soon as you make it available on crates.io so it builds for everyone.

[zonyitoo]

I already merge it to the master branch, but since the simd crate is not ready for pushing to crates.io, I have to wait ...

[dpc]

No hurry. :)