Why did you remove libuv?

[ibsusu]

Hiya!

I'm just wondering why you removed libuv, no judging, I just ended up in this repo in my quest to integrate the aws cpp s3 sdk into my event loop utilizing server.

Thanks for your time!

[bretambrose]

Unsure what you're referring to here. I recall talk of supporting libuv in order to make the javascript integration more natural but that was two years ago. The aws-c-* library set, by design, has no dependencies outside the control of AWS until you hit the operating system.

Thinking back further, I do vaguely recall that a libuv-based event loop hit a brick wall at some point, but I don't know the details. @JonathanHenson might remember why that effort stalled.

[ibsusu]

Thinking back further, I do vaguely recall that a libuv-based event loop hit a brick wall at some point, but I don't know the details. @JonathanHenson might remember why that effort stalled.

I think that's what I'm referring to. #156

It was ripped out for some reason and I'd just like to know why. epoll and kqueue are used instead so it obviates the need for libuv so it just made me curious what the reasoning was.

[JonathanHenson]

The threading model was incompatible. Also libuv is level-triggered and that detail permeates the rest of the API. The common runtime uses an edge-triggered model and they weren't compatible without a lot of complexity and overhead. Technically libuv is still used by V8 and the CRT shunts data over to it to interact with javascript.

Furthermore, implementing back-pressure was particularly messy since it's not a concern libuv ever assumes given the js threading model and the library's memory model. We still had libuv loops for interacting with js, but the napi added additional async support and we were able to use that instead and eventually were able to completely remove it.