On Sun, Mar 22, 2020 at 12:56:16PM +0800, CandyMi <869646...@qq.com> wrote:
> I have the same opinion about Linux aio and io_uring. The performance of aio 
> is not as good and problematic as described, but the use of io_uring may be 
> limited by the version of the Linux kernel and it makes me hesitant.
> 
> There may be very few people who follow up on Linux 4.x / 5.x aggressively, 
> that is to say, there will be very few people who actually use it! And I also 
> have to maintain the old 2.6.32 kernel project).

Actually, I would assume most people are now on a 4.x kernel, but of
course, select and poll keep being supported and lubev will fall back to
these if required.

> The following code is my implementation of the IO watcher wrapper. The only 
> difference is: "the IO watcher passed to the core IO init method may have 
> called the core IO stop multiple times (object reuse). Such behavior is to 
> reduce the frequent creation or destruction of IO watcher."

This got rather garbled, but I have one comment:

> core_io_stop(core_loop *loop, core_io *io){
>       if (io-&gt;events || io-&gt;fd){

If you want to check whether a watche ris active (strated), you could use
ev_is_active(w).

Your current if has the disadvantage of not stopping all acive watchers,
as 0 is a valid value for both fd and events.

>               io-&gt;fd = io-&gt;events = 0x0;

Also, after stopping, you can reuse the watche rmemory in any way you like,
but you then cannot start it again without calling ev_io_init.

> It is worth mentioning the use of the ev_timer_again method: "The consequence 
> of modifying timer-&gt; repeat is that it will cause the min-heap to be 
> adjusted every time. Will frequent use have a certain impact or even worse 
> performance?", Because The implementation of ev_timer_again is this (v4.25):

While other data structures are possible, and I vaguely plan some minor
optimisations, when you use ev_timer_again, libev of course has to adjust the
heap to reflect the new reality. ev_timer_again is typically faster than a
stop/start though, which is why it exists.

Depending on your needs, you may be able to further optimize timers by not
updating them at all on every change (e.g. for network timeouts, letting
them expire and reschedule to the real timeout in the callback), or by
creating your own data structure, e.g. if you have a lot of timers with
the same timeout, you can put them into a linked list and only create a
real timer for the next timer in that list, adding new timers to th end
and so on.

> Recently, I was watching the code of libeio. When will libeio be ready to 
> release the official version?

I can call it an official version right now and create a CVS tag if that
helps you. The main blocking issue is probably the lack of documentation,
and some doubts on whether this is really the right API.

And of course, libeio might profit most from io_uring.

In terms of stability, libeio is pretty much stable and in maintenance for
a decade now.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schm...@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Reply via email to