search

edef1c / libfringe

a Rust library implementing safe, lightweight context switches, without relying on kernel services
https://edef1c.github.io/libfringe
Apache License 2.0
512 stars 31 forks source link

Windows Fiber Support #71

Closed cramertj closed 7 years ago

cramertj commented 7 years ago

I threw together this gist using Windows Fibers to make something akin to libfringe.

The big difference is there isn't any way (as far as I can tell) for the user to provide their own pre-allocated stack. This is makes Fibers somewhat incompatible with libfringe's design.

I can see a couple ways around this:

  1. Have OsStack on Windows correspond to a pre-allocated fiber which can be passed different FnOnces as trait objects. This would introduce extra runtime cost (dynamic dispatch and possibly boxing) and wouldn't work for SliceStacks. It's also misleading, since OsStack wouldn't really be a "stack" in the traditional sense-- just a pointer to a fiber.
  2. Just use OsStack on Windows as a way to store the desired stack size (i.e. OsStack would just be the stack config, not the real stack itself). This would allow the API to match across systems, but would be misleading to users. It also wouldn't work for SliceStacks.
  3. Provide slightly different APIs on different systems and force users to cfg their code. This is kind of lame, but possibly justified given the inherent difference in design between the systems.
  4. Create a higher-level API that doesn't expose stacks in the same direct way, making it compatible with both designs. This would probably require some performance tradeoffs.

Thoughts?

whitequark commented 7 years ago

So, I also came up with the idea of using fibers on Windows earlier. Personally, it is my view that a higher-level library should use either libfringe or fibers, depending on the platform. There is no obvious way to provide the guarantees that libfringe does on top of the fiber interface; importantly, the ConvertThreadToFiber function is not idempotent and requires keeping track of global (really thread-local, which makes it worse) state to determine if it's safe to call, which is obviously unwelcome in a library like libfringe.

cramertj commented 7 years ago

That was the (unfortunate) conclusion I reached as well. I'll close this, then, and perhaps start working on a wrapper that works with both libraries.