Skip to content
This repository has been archived by the owner. It is now read-only.

unix: remove libev #485

Closed
bnoordhuis opened this issue Jul 2, 2012 · 26 comments
Closed

unix: remove libev #485

bnoordhuis opened this issue Jul 2, 2012 · 26 comments
Labels

Comments

@bnoordhuis
Copy link
Contributor

@bnoordhuis bnoordhuis commented Jul 2, 2012

This issue tracks the removal of libev in v0.9 / master.

@ghost ghost assigned bnoordhuis Jul 2, 2012
@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Jul 2, 2012

In case any project watchers are wondering, libev served us well but:

  1. It only supports level-triggered I/O. On Linux, we want to use edge-triggered mode - it cuts down the number of syscalls by a substantial margin.
  2. libev's inner loop does a lot of things we don't really need. Gutting the inner loop like we did in 649ad50 gave a 40% performance increase on some benchmarks.

@nathansobo
Copy link

@nathansobo nathansobo commented Aug 2, 2012

@bnoordhuis: Will this result in a single event loop shared between Unix and Windows versions of the library? Will the interface to it be sufficiently abstract that it might be possible to replace it with a different event loop? The Chromium Embedded Framework maintainer and I are interested in getting libuv working on top of Chromium's render process event loop as a means of making the Node.js API available from JavaScript in a Chromium window. We're curious about the roadmap for removing libev, since we're thinking this attempt will be easier once libuv has its own event loop.

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Aug 2, 2012

Will the interface to it be sufficiently abstract that it might be possible to replace it with a different event loop?

If you mean 'will it be possible to embed libuv in another event loop?' then the answer is yes. We'll give you a timeout and something (file descriptor, handle) to poll on in your own event loop.

@nathansobo
Copy link

@nathansobo nathansobo commented Aug 3, 2012

That sounds much easier than what I had in mind. So presumably you'll expose a function as part of the public interface that we can call when the file descriptor changes to invoke the appropriate callbacks? Very excited about this. Godspeed.

@milani
Copy link

@milani milani commented Aug 6, 2012

@nathansobo We could bring nodejs APIs to CEF using proxies in AppJS. But it's better to merge the event loops. Someone did it and published under the name node-webkit you maybe heard of.

@nathansobo
Copy link

@nathansobo nathansobo commented Aug 7, 2012

@milani Yes, but Marshall Greenblatt (the author of CEF) has concerns about the way it was done. He says that the event loops are highly optimized to maximize performance on the OS, so he's concerned that moving to an event loop based on libuv directly could negatively impact performance. He prefers an approach where the default Chromium event loop remains intact, driving libuv with the Chromium event loop rather than the other way around. I think only way to do that efficiently is with an API like @bnoordhuis describes, where you can have the main event loop wait on a file handle / timeout. Thoughts?

@jbergstroem
Copy link

@jbergstroem jbergstroem commented Aug 9, 2012

Close?

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Aug 9, 2012

Close?

Close but not quite there yet, if that is what you mean. :-)

@jbergstroem
Copy link

@jbergstroem jbergstroem commented Aug 9, 2012

@bnoordhuis indeed ^_^

@denik
Copy link

@denik denik commented Oct 6, 2012

Once edge-triggered epoll is used, will Poll watchers become edge-triggered too? or will you implement level-triggered Poll on top of edge-triggered epoll?

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Oct 6, 2012

@denik Poll watchers will default to level-triggered mode. I may add a flag for edge-triggered mode.

FWIW, I'm reconsidering edge-triggered mode. It reduces the number of system calls substantially but it slows down some benchmarks because a lot more time is spent inside kernel-side spinlocks. :-(

It's probably because everyone and his dog uses level-triggered mode and as a result that code path has seen a lot more optimization. I may send some patches to the LKML but that doesn't help us in the near future.

@zcbenz
Copy link

@zcbenz zcbenz commented Oct 10, 2012

@bnoordhuis When will libev be completely removed? I've waited this for a long time :)

And will libuv provide an API like uv_backend_fd() to help integrating libuv to other event loops after libev is removed?

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Oct 10, 2012

When will libev be completely removed?

It's mostly done, I just need to clean it up a little. Time permitting, I'll land it this or next week.

And will libuv provide an API like uv_backend_fd() to help integrating libuv to other event loops after libev is removed?

Yes. And mea culpa, that's long overdue.

@TooTallNate
Copy link
Contributor

@TooTallNate TooTallNate commented Oct 10, 2012

And will libuv provide an API like uv_backend_fd() to help integrating libuv to other event loops after libev is removed?

I believe this thread on the libuv mailing list is related: https://groups.google.com/d/topic/libuv/qSSaBRBwFoY/discussion

@nathansobo
Copy link

@nathansobo nathansobo commented Oct 23, 2012

@bnoordhuis is the code for removing libev visible publicly on a branch somewhere? I'd love to get a look at progress.

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Oct 23, 2012

@nathansobo Sure, it's in my rm-ev branch.

@bnoordhuis
Copy link
Contributor Author

@bnoordhuis bnoordhuis commented Nov 16, 2012

Fixed in 1282d64 and 665a316.

@nathansobo
Copy link

@nathansobo nathansobo commented Dec 7, 2012

@bnoordhuis Any updates on uv_backend_fd()?

@indutny
Copy link
Contributor

@indutny indutny commented Dec 7, 2012

@WabidWombat
Copy link

@WabidWombat WabidWombat commented Apr 12, 2016

I am tasked with porting some server code from *nix to Windows. The code was written using libev and libeio, each of which I am at best marginally familiar with. At this point the choice is to either (1) make the libeio and libev code Windows-happy, or (2) port it to libuv.

Can anyone give me a rough idea of the relative difficulty/merits/demerits? I am just looking for order-of-magnitude here.

By the way, the select() barrier of 64 connections and the related performance issues loom large in our application.

Thanks

@indutny
Copy link
Contributor

@indutny indutny commented Apr 12, 2016

@WabidWombat I would suggest using porting to libuv. There are lots of edge cases to deal with, and lots of similarities between libev's API and libuv. Should be much easier than writing everything from the scratch.

@WabidWombat
Copy link

@WabidWombat WabidWombat commented Apr 12, 2016

To make sure I understand you - you are recommending porting the existing code onto windows, rather than using libuv?

@indutny
Copy link
Contributor

@indutny indutny commented Apr 12, 2016

My english is far from my own expectations, sorry! I suggest using libuv.

@WabidWombat
Copy link

@WabidWombat WabidWombat commented Apr 12, 2016

спасибо!

@dawud-tan
Copy link

@dawud-tan dawud-tan commented Oct 9, 2016

@bnoordhuis so, currently, libuv doesn't use epollet yet?

@saghul
Copy link
Contributor

@saghul saghul commented Oct 10, 2016

No it does not.

On Oct 9, 2016 20:20, "陳大衛" notifications@github.com wrote:

@bnoordhuis https://github.com/bnoordhuis so, currently, libuv doesn't
use epollet yet?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#485 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATYGJYKmrrD3ZPVQsGsORXM6zbgACuOks5qyT5ugaJpZM4ADX8z
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests