[int_19h]

The problem with fibers is interop. The moment you need to do some FFI, especially FFI that involves callbacks, things get a lot more complicated, since code you're calling into/through doesn't have any of that fiber magic (and, depending on how you implemented yours, it might actually break it).

[sifoobar]

Another win for embedded languages/inside-out FFI in my book, since controlling the outside world (C in Snigl's case) makes it trivial to register a trampoline with whatever state needed to deliver the call.

[int_19h]

Sure, but now you need C code that needs to be aware of your trampoline, specifically. Good luck if it's an existing library. Also, what happens if there are multiple interleaved C parts of the stack, and the innermost one invokes the trampoline? What happens to the ones in the middle? It all sounds awfully like setjmp/longjmp (which is the one thing that you never do in C if you want to interoperate with anything in a sane fashion).

And I don't think FFI direction matters much. The moment you have callbacks, your stack has interleaving of languages anyway (i.e. X called into Y which called back into X). Does it really matter which language the innermost and the outermost stack frames belong to? You still need to handle the mix in the middle.

[sifoobar]

Why? You really only need the C library to be able to pass a data pointer to the callback, and most do.

This sounds like a native compiler perspective to me; with pure VM fibers like Snigl's these are not issues.

It's not about direction, it's about controlling the world from the outside.

You sound more like you're on a mission to prove to the world it's impossible, since Rust didn't manage to get it right.

[int_19h]

What happens with all the interleaving stack frames when that callback gets invoked?