3 ms·
This article is a bit mixed, audience wise. If you need the first section telling you what userpace M:N scheduling is, you really shouldn't be using the second
by rkangel 6y ago
This article is a bit mixed, audience wise. If you need the first section telling you what userpace M:N scheduling is, you really shouldn't be using the second part to implement a runtime for it. You can run into any number of subtle issues that will manifest with weird behaviour and be very hard to debug.
If you have to use C/C++ use a library that has done it for you. If you don't then you can use Rust, Go or Erlang/Elixir all of which have excellent implementations.
- junon 6y agoMeh I don't like the absolutism in this comment, personally. I'm well versed in coroutines and "fibers" and all of the theory surrounding it but haven't come across the formalized terminology (m:n, n:1, etc.). I'll give you another example: ropes are string classes with more complex data storage, useful for optimizing mutations and cutting down copies. The concept is easy to understand, and personally I've implemented them a number of times, but didn't know about the formalized term until the last year or so. The last sentence is a bit unfair and presumptuous, I think.
- rkangel 6y agoPerhaps it was a little absolutist. Maybe it would be better written like this: If you're not familiar with implementing schedulers and concurrent systems then beware that implementing fibers from scratch is likely to result in some subtle and hard to debug problems. If you have to use C/C++ you may well get better results using a library. If you aren't tied to the language then Erlang/Elixir, Go and Rust all have excellent implementations that have more language support.
- dosshell 6y agoI dont't agree. I'm not used to implement schedulers and concurrent systems and I wrote my own fiber-system in C a couple of months back (https://gitlab.com/dosshell/tinyfiber https://gitlab.com/dosshell/tinyfiber) after listening to the famous talk from Christian (mentioned in article). Its a bit messy, sure. But I don't think I have any subtle bugs and was not hard to debug. Performance is good too. What I want to say is: it is easy to do, even I can :P
- gpderetta 6y agoif you are not familiar with implementing schedulers and concurrent systems but you are interested, do it! It is fun and and great learning experience. Doesn't mean you have to deploy it to prod, it can be a personal project.
- rkangel 6y agoThis is an excellent point. Experimentation is always a good idea. I have just got cynical and conservative about what I choose for the basis of production systems. Actually for full disclosure I should say that I am currently building a telecomms system in Elixir. I find the decades of battle testing in the BEAM reassuring.
- gpderetta 6y agoI have written half a dozen coroutine and m:n schedulers for fun. I never once used them professionally to avoid the hammer-nail problem :)