[qwe123_troll]

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]

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]

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]

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).

[eps]

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

[qwe123_troll]

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.