3 ms·

Lemme see if I understood this right: you rewrote a large part of the kernel because you think your code will be better than code that's been tested by (literal

Lemme see if I understood this right: you rewrote a large part of the kernel because you think your code will be better than code that's been tested by (literally!) billions of people over the course of 15 years? Not that there is anything wrong with this approach (I rewrote glib'c memory allocator, which is atrociously broken for modern systems), but you better have a very good explanation for why you did this. P.S. I won't touch on the fact that a good scheduler will necessarily need to run in kernel-mode, not user-mode. But that's a subject for another discussion.

halayli 15y ago
This has nothing to do with the kernel scheduler. lthread is a coroutine library, you can think of it as a micro task scheduler inside the process (userland). It's ideal for socket programming because it avoids using callbacks and minimizes complexity.
- qwe123_troll 15y ago
  It has everything to do with the kernel. You've taken a piece of code that belongs in kernel-space and put it into a user-space process. There might be valid reasons to do so, but since I haven't seen any good explanation I'd just assume this project was coded for lulz or out of technical ignorance. P.S. "avoids callbacks" and "minimizes complexity" is a red herring; all threaded code has these properties, regardless of how the threading engine is implemented behind the scenes.
  - beagle3 15y ago
    It has _little_ to do with the kernel. There, are we friends yet? Here's a valid explanation, which wasn't explicitly given, although it was hinted at: kernel threads take resources that become significant when you want a very large number of threads (say, one million). The per thread overhead, including user stack, kernel stack and control structures are at a minimum of ~8K. That's 8GB for a million threads before you actually get to do anything useful. However, lthreads can realistically take as little as 100 bytes per thread, which puts us at a 100MB footprint for the same case. That's a huge difference. There are tradeoffs, but that's a potentially useful use case which kernel threads do not support (and which, in general, requires async programming, which lthread implements while emulating a thread API).
    - qwe123_troll 15y ago
      > Here's a valid explanation, which wasn't explicitly given, although it was hinted at: kernel threads take resources that become significant when you want a very large number of threads (say, one million). Untrue. Kernel threads take the same amount (plus or minus) of resources as userland threads. You probably don't believe me; that's fine. But at least have the decency to test your preconceptions empirically. It's ridiculous that people parrot these hoary old memes dating back to 1995 when writing a simple program to see for yourself would take literally 15 minutes. P.S. Creating 1 million threads is never a valid solition for any problem.
eps 15y ago
That's a valid comment. The tone is all wrong, but I guess it's intentional judging by the nick.
- qwe123_troll 15y ago
  Heaven knows that having to act all politically-correct and tender-footed in the face of technical incompetence on the Internet, of all places, would drive me insance. I get enough of that icky stuff at work.

halayli 15y ago

This has nothing to do with the kernel scheduler. lthread is a coroutine library, you can think of it as a micro task scheduler inside the process (userland). It's ideal for socket programming because it avoids using callbacks and minimizes complexity.

qwe123_troll 15y ago
It has everything to do with the kernel. You've taken a piece of code that belongs in kernel-space and put it into a user-space process. There might be valid reasons to do so, but since I haven't seen any good explanation I'd just assume this project was coded for lulz or out of technical ignorance. P.S. "avoids callbacks" and "minimizes complexity" is a red herring; all threaded code has these properties, regardless of how the threading engine is implemented behind the scenes.
- beagle3 15y ago
  It has _little_ to do with the kernel. There, are we friends yet? Here's a valid explanation, which wasn't explicitly given, although it was hinted at: kernel threads take resources that become significant when you want a very large number of threads (say, one million). The per thread overhead, including user stack, kernel stack and control structures are at a minimum of ~8K. That's 8GB for a million threads before you actually get to do anything useful. However, lthreads can realistically take as little as 100 bytes per thread, which puts us at a 100MB footprint for the same case. That's a huge difference. There are tradeoffs, but that's a potentially useful use case which kernel threads do not support (and which, in general, requires async programming, which lthread implements while emulating a thread API).
  - qwe123_troll 15y ago
    > Here's a valid explanation, which wasn't explicitly given, although it was hinted at: kernel threads take resources that become significant when you want a very large number of threads (say, one million). Untrue. Kernel threads take the same amount (plus or minus) of resources as userland threads. You probably don't believe me; that's fine. But at least have the decency to test your preconceptions empirically. It's ridiculous that people parrot these hoary old memes dating back to 1995 when writing a simple program to see for yourself would take literally 15 minutes. P.S. Creating 1 million threads is never a valid solition for any problem.

eps 15y ago

That's a valid comment. The tone is all wrong, but I guess it's intentional judging by the nick.

qwe123_troll 15y ago
Heaven knows that having to act all politically-correct and tender-footed in the face of technical incompetence on the Internet, of all places, would drive me insance. I get enough of that icky stuff at work.