It is! I remember seeing the old ucontext-based C coroutine library(ies?) and being fascinated by how they worked.
Your argument makes sense. One can’t introduce a new type of thread that the rest of the OS is unaware of, without being extremely careful about what the code running on such threads is allowed to do.
Also wouldn’t this break compatibility with C libraries? If the mutex implementation in C++ is fiber aware, but the one in C is not (unless you add fibers to libc), then C++ code could never call C code that takes a mutex, since it’d block and break fiber scheduling.
Same for callbacks from C to C++.
(Kind of like how Lwt code in OCaml cannot call Unix functions that block, but this isn’t enforced or checked anywhere)
Yes, that’s one of the points I make in the paper.
Languages like OCaml and Java can have fibres / green threads because they have a very clear distinction between code in their language and foreign code. It’s possible to either say to the programmer ‘don’t call native things if you’re using this’ or have the VM handle the special cases. I’m not sure what Go does now, but it also did have special handling for things that called C routines from a goroutine to make sure the stack was big enough and so on.
You can’t do this in C++. There is no indication that you’re calling non-C++ code.
Has Microsoft abandoned the Windows fibres support, or is the C++ fibres proposal an effort to wedge it into other operating systems?
Regarding features that are both architecture- and OS-dependent, doesn’t that include TLS and exceptions? Possibly also mutexes and other thready things?
Microsoft rarely removes things, but they now recommend people not to use fibres. In the UWP days, they recommended fibres to the extend of banning thread-local storage.
Oh, I wrote this! Not sure if it’s interesting to people here.
It is! I remember seeing the old ucontext-based C coroutine library(ies?) and being fascinated by how they worked.
Your argument makes sense. One can’t introduce a new type of thread that the rest of the OS is unaware of, without being extremely careful about what the code running on such threads is allowed to do.
Also wouldn’t this break compatibility with C libraries? If the mutex implementation in C++ is fiber aware, but the one in C is not (unless you add fibers to libc), then C++ code could never call C code that takes a mutex, since it’d block and break fiber scheduling. Same for callbacks from C to C++.
(Kind of like how Lwt code in OCaml cannot call Unix functions that block, but this isn’t enforced or checked anywhere)
Yes, that’s one of the points I make in the paper.
Languages like OCaml and Java can have fibres / green threads because they have a very clear distinction between code in their language and foreign code. It’s possible to either say to the programmer ‘don’t call native things if you’re using this’ or have the VM handle the special cases. I’m not sure what Go does now, but it also did have special handling for things that called C routines from a goroutine to make sure the stack was big enough and so on.
You can’t do this in C++. There is no indication that you’re calling non-C++ code.
Has Microsoft abandoned the Windows fibres support, or is the C++ fibres proposal an effort to wedge it into other operating systems?
Regarding features that are both architecture- and OS-dependent, doesn’t that include TLS and exceptions? Possibly also mutexes and other thready things?
Microsoft rarely removes things, but they now recommend people not to use fibres. In the UWP days, they recommended fibres to the extend of banning thread-local storage.
Can we find this in html, markdown or even txt form? Those margins are killing me.. 🫠
https://github.com/jbcoe/cpp-fibers-rebuttal
(I thought the margins were great)