3 ms·

Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Example, say I have a thread with a wren v

Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Example, say I have a thread with a wren vm instance running with a bunch of fibers inside, and a fiber calls back to a C function that's blocking (on io say) then this still blocks the entire thread. Seems like there'd have to be a way to integrate with an event loop, and register a fiber with an event (edit or file descriptor/socket). Contemplating this makes me sleepy and grouchy ie it's very abstract, have you given any thought to this use case?

munificent 12y ago
> Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Think of them as a way to organize your program, not a way to optimize it. Fibers let you have multiple independent imperative flows of behavior that you can bounce between without having to return from one in order to get to the other. Instead of always having to organize your behavior in a single rigid stack of "can't do X until done doing Y", you can have as many separate stacks as you want. You can also hook them up to something like asynchronous IO where an IO operation will implicitly park a fiber and let others run. I did that using libuv in my other language Magpie [1]. That's also really nice, but it naturally requires more low level support and has some implications on how fibers are scheduled. In Wren, fibers are explicitly cooperative—you specifically choose which fiber to resume when you suspend one. If you're parking on IO, you need some more implicit logic so the scheduler can automatically pick a fiber to resume. In practice, I think that just means that if all fibers are parked waiting on IO, the scheduler resumes whichever one's IO operation completes first. [1]: http://magpie-lang.org/ http://magpie-lang.org/
- marktangotango 12y ago
  Great insight, thanks. I'll take a look at magpie.

munificent 12y ago

> Seems like fibers/coroutines are a curiosity here, how useful are they supposed to be from a performance perspective? Think of them as a way to organize your program, not a way to optimize it. Fibers let you have multiple independent imperative flows of behavior that you can bounce between without having to return from one in order to get to the other. Instead of always having to organize your behavior in a single rigid stack of "can't do X until done doing Y", you can have as many separate stacks as you want. You can also hook them up to something like asynchronous IO where an IO operation will implicitly park a fiber and let others run. I did that using libuv in my other language Magpie [1]. That's also really nice, but it naturally requires more low level support and has some implications on how fibers are scheduled. In Wren, fibers are explicitly cooperative—you specifically choose which fiber to resume when you suspend one. If you're parking on IO, you need some more implicit logic so the scheduler can automatically pick a fiber to resume. In practice, I think that just means that if all fibers are parked waiting on IO, the scheduler resumes whichever one's IO operation completes first. [1]: http://magpie-lang.org/ http://magpie-lang.org/

marktangotango 12y ago
Great insight, thanks. I'll take a look at magpie.