libev VS HTTP Parser

Thank you for this.

I am interested in how concurrency can be represented elegantly and efficiently, so I am interested in how libraries can simplify async and make it easier to reason about and write

The libev and ioring support is great for IO scalability (https://github.com/enki/libev not sure if this is the official repo)

In Python I use the "select" module and use epoll on Linux.

I am currently thinking of designing an API that allows the registration of epoll-like listeners to arbitrary objects, including business objects, so you can efficiently register a listener on multiple behaviours of multiple arbitrary objects.

I wrote an async/await simulation in Java and my scheduler is really simple, it's just a for loop that checks to see if there are any tasks that can progress. I notice the switch_fiber in polyphony must do something similar. This is similar to a yield in a coroutine.

My async/await simulation takes the following program:

  task1:

Also, libev

It's done even now. See ev.h where they do this. Just that you disable GCC's aliasing warning. There's a reason why restrict and aliasing became important to deal with. It wasn't standards that killed it.

It looks not too different from the majority of HTTP parsers out there written in C. Here is an example of NodeJS [0].

[0] https://github.com/nodejs/http-parser/blob/main/http_parser....

NodeJS's HTTP parser used to be a handwritten C lib: http-parser

Whoa, I didn't know that! But yeah, it seems like https://github.com/nodejs/http-parser is based on nginx. It now uses https://github.com/nodejs/llhttp but has some of the same legacy.

On the other hand, deno's HTTP stuff is built on top of Hyper, a Rust library https://github.com/hyperium/hyper

Boost.Beast has its own HTTP parser[0], during the development of which Vinnie Falco (the principle author of Beast) found many bugs/inconsistencies in Node.js's own parser[1]

[0] https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b...

[1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...

For cases where it is necessary to pass local information to/from a callback, the http_parser object's data field can be used.

Legacy HTTP/1.1 suffers a few issues, see the current RFC errata:

https://www.rfc-editor.org/errata_search.php?rfc=7230&rec_st...

There are issues particularly around how whitespace and obsolete line folding should be handled

https://github.com/nodejs/http-parser/issues?q=is%3Aissue+wh...

https://github.com/httpwg/http-core/issues/53

It's not as trivial as a few string splits.

There's picohttpparser and the one used in node.js: https://github.com/nodejs/http-parser