My personal reason for replying to your email so late! I am very sorry. Thank you for pointing out the problem of the mail format. Currently I use a browser to send mail. This format is likely to cause special characters to escape. I think I will try to improve it.
--- I simulated the ev_once method in my own way, and cached the io watcher and timer watcher objects to achieve more efficient (memory) reuse; this can be seen from some test cases I wrote for this. The "memory stability" aspect does work really well. The project in my production environment needs to run at least 5000 requests / response scenarios per second (single process / single thread). The start and stop operations of this frequency are not expensive for an O(log n) operation, but In the "Flame Graph", its calling frequency ranks in the forefront. Although I haven't encountered any real performance doubts (not encountered yet), At present, I have completely disabled (can enable) the timer watcher, the purpose is to reduce the creation of a large number of timers and make it more suitable for the connection pooling characteristics of the load balancing software. It is mainly the above-mentioned "foresight" (perhaps stupid), and the analysis of the frequency of calls according to the method of "flame graph" makes me doubt about its practicality. (Please don't blame it) :) My idea: if there is no "painless" O(1) complexity operation, then I will try to minimize the coexistence of O(log n) complexity operations. --- Currently, I use ibev as the underlying event driver to drive a scripting language (Lua) to complete business logic. At the beginning, I considered the "minimum heap and time wheel" approach, but the actual performance is even worse. The reasons are as follows: 1. The interaction overhead of the "glue layer" between the two languages will increase, making me unable to determine whether it will work better. 2. The native runtime overhead of the lua language is 30 times slower than that of the C language, which makes me not necessarily improve the efficiency even when completed in the lua layer; --- I understand very well that you want to make libev more general, but sometimes there are always "choices". I think this may have a bad impact on your optimization of libev. At the same time, I very much hope that libev will often have some "breakthrough" features to better give users some "surprises". :) --- Finally, I have started porting libeio to my web development framework, and I have begun to perform stability tests on this "feature" in a test environment. I hope you can "clearly" release a stable version of libeio instead of letting us get it from "cvs". Known issues: 1. Simultaneously generating a large number of eio_req causes lock contention overhead of multiple threads than a single thread to complete synchronous I / O operations will aggravate the deterioration of CPU usage; (maybe I use it incorrectly) 2. The file descriptor (fd) created (obtained) by the fileno (FILE * f) method cannot complete the "cache" flush of setvbuf to disk using * sync; (maybe I used it incorrectly) 3. In the msys2 (cygwin) simulation environment, libeio fails to control the number of threads; _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
