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