acidx

I'm not aware of it. I'm learning Rust (just bought the "The Rust Programming Language" book, FWIW), so I will check it out.

Ah, yes, I'm very aware of libtls. The API is indeed nice, but it would require some changes in Lwan that I'd rather avoid; for instance, every socket call would need to be virtual, and it would not be possible to use something like sendfile() or mmap() a file and writev() it to the socket.

I'd like to use BearSSL, which is a nice, clean implementation of TLS, makes no memory allocation (so it fits Lwan architecture very well)... but only for the initial connection handshake; I'd then hand over TLS to the Linux kernel with kTLS (https://netdevconf.org/1.2/papers/ktls.pdf). However, there's not much beyond some tests in that front.

Yes, Lwan's thread scheduler is pretty simple, and can be borderline useless if a thread blocks. This 2014 blog post has more details; not much in that regard has changed since then: https://tia.mat.br/posts/2014/10/06/life_of_a_http_request.h...

Server-sent events: https://en.wikipedia.org/wiki/Server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

Curious that you compare Seastar with a Ferrari: those cars are known for an internal finish that's not compatible with their price tag... and Seastar is nothing like that. It's a seriously well engineered piece of software, and it shows: its readability and code quality is superb.

There is SSE, which, although unidirectional, can be used in lieu of websockets for a chat application (receive messages/events via SSE, send via another endpoint).

However, as I said before, this is an open source project; if you have an itch, you can scratch it. PRs are open. :)

Because I failed to move the benchmark harness from the Lwan repository to the TWFB repository. Also, I'm not really spending a lot of time on Lwan any longer; there are so many things I'd like to do, and so little time. :)

The authors of Seastar used to use Lwan to benchmark their HTTP server implementation. When Seastar isn't using DPDK/usermode TCP stack, and drops to the POSIX API, Lwan is still faster.

It's a known issue with TWFB. I don't know if they're planning on fixing it, but most frameworks that are not in newer rounds are not appearing in older rounds any longer.

Yes, the small footprint was a deliberate choice, specifically for the embedded scenario. One of the things I did back in the day was to run Lwan+Lua on an Intel Galileo board, without an SD card (it has only 4MB of flash memory, which has to fit the Linux kernel, some minimal userland, and Lwan+Lua).

TLS is hard given the current architecture, but I've been investigating kTLS, so maybe it'll happen someday. I would appreciate help on this front, though.

Thanks! Code readability is important: not only for others (it's an open source project, and contributions are welcome!), but for myself... I have terrible memory. :)

The reason struct typedefs are avoided is because I prefer to be explicit (the "Zen of Python" isn't just for Python!). It's also common practice in most of the projects I work on, and it's not much of an issue for me as far as a little bit of typing goes: I'm a fast typist.

Yes. Team. http://www.commitstrip.com/wp-content/uploads/2014/05/Strip-...

Thank you! Although I've used a lot of tricks I've learned over the years in this project, I took a lot of inspiration from Go.

In the works? No. Planned? Yes. I've been playing around with kTLS/BearSSL but so far I haven't made any stride. PRs, my inbox, and the IRC channel are open, though!

Depends how you measure it.

A long time ago I benchmarked it, and Lwan came out on top, performance-wise. However, performance isn't the only thing that matters in a piece of software like this.

H2O is a great project; in fact, the authors were tightly involved in the definition of HTTP/2.0, and it is one of the first servers to support this version of the protocol. It is well written, and easy to grok the code. Some of its byproducts include a nice (and reusable) HTTP parser library, and clever tool named qrintf (that pre-parses the format string passed to printf()-family functions and generates optimal code for that).

Also, there's a company behind it -- Lwan is just a toy I work on the weekends when I feel like it.

This whole project started as a joke, and I still see it as such.

Author here. It's a pun on another similarly-named web server. It's a terrible name, and I should have searched the web before, but it's too late now.

I'm left-handed and I have no problems when using a fountain ink pen... if I write upside down.

Shameless plug, inspired by pledge(2), if you're a Linux rather than BSD person: how to use elementary virus writing techniques to sandbox programs under Linux using seccomp-bpf: https://tia.mat.br/posts/2016/11/08/infect_to_protect.html

Kind of. I've tried making the page just as phony, but that's more difficult than it sounds.

It's possible with FFI, yes, but it's not the way it's currently done in Lwan.

That's not the only joke in the feature list (or the whole page, to be honest.)

It builds on FreeBSD (soon OS X), but it's not working yet.

My web server, uses the same pattern. There's an article explaining it in details here: http://tia.mat.br/posts/2014/10/06/life_of_a_http_request.ht...

Would a 2-lines nibbles game be better?

I've just typed the implementation by Ricardo Bittencourt (http://www.ricbit.com/mundobizarro/twoliners/) and it works. BGM included: https://imgur.com/a/PnE0s

The presentation gutomaia did on PyNES at PythonBrasil had a slide deck written using this tool.

Not sure if something like this should be part of glibc. Just recently there was an ABI break due to the fact that jmp_buf is exposed in the headers to allow embedding the struct[1].

[1] https://lwn.net/Articles/605607/

(Also, I ended up mixing up ucontext.h with setjmp.h in my comment above; Lwan uses ucontext.h as a fallback. There are coroutine implementations that will use setjmp/longjmp, or at the very least reuse the jmp_buf struct and roll their own asm, though.)

Yeah, that's how you end up doing this: store coroutine state in a struct, with an integer that lets you decide where to jump to when you resume the coroutine. With compiler support that can be pretty efficient (gcc has computed goto, for instance). Things get quite awkward in C but similar techniques are manageable in C++.

I've never used Protothreads before, but Contiki (the tiny operating system written by the same person) uses them for its process implementation.

Similar technique is also used by Putty as well: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

setjmp()/longjmp() will work, but they're sort of inefficient as, at least under POSIX, they will save and restore the signal mask, which makes for two round-trips to the kernel just for a coroutine context switch.

My web server uses coroutines, and for x86 and x86-64 it uses open-coded assembly routines to yield/resume, with fallbacks to setjmp()/longjmp() on other architectures.

It works fairly well, performance-wise. In fact, it's one of the top-performing servers/frameworks in the TechEmpower's Web Framework benchmarks[1].

I wrote a similar article explaining how everything is put together here[2].

[1] https://www.techempower.com/benchmarks/ [2] http://tia.mat.br/blog/html/2014/10/06/life_of_a_http_reques...

Read Adam Dunkels' paper on Protothreads.