vier

Why less memory than segmented stacks?

Lthread is a cool experiment but coroutines in C is a dubious ideal. If you're writing a program in C/C++, presumably you want ultimate control and the fastest possible execution. You wouldn't introduce extra runtime complexity and a speed hit for easier to use APIs (blocking I/O functions). You'd just use epoll and non-blocking sockets (or libuv). That's not to say that coroutines/green threads/goroutines in high-level languages where you've already decided to take a speed hit for easier use isn't useful. Said another way: if your concern is about easy to read code, C is not the right choice; if your concern is speed: copying a stack on every i/o function is not the right choice.

The luvit page notably lacks a link to libuv - the I/O engine behind it.

https://github.com/joyent/libuv

digressing from luvit...

how does the stack copying technique (as used in lthread) compare to segmented stacks (as used in go)? The swap technique is very simple but I would assume that the stack copy shows up in profiles and is significantly slower than the segmented stack technique... Are there any benchmarks?

it's a build dependency not a runtime dependency

I don't know any drug dealers who take that.

Using libuv from Node.js too. Awesome.

Here are some numbers from last month https://gist.github.com/1166690

see http://joyeur.com/2011/08/11/node-js-meetup-distributed-web-...

Don't miss the video http://vimeo.com/11613517

Grow up. C programs are ported painfully to each operating system. This is the reality programming in C. If the author does not support your system, he simply has not spent the time to port it. Proper autoconf tests isn't going to magically make software run on BSDs because the proper test won't be apparent until the author attempts to compile on BSDs. Does it suck? Yes. Has it ever been any different? No.

Are you kidding? What is this: http://www.google.com/codesearch/p?hl=en#zAePDxanDsk/openamq...

that's exactly what it's doing