Home > other >  The libev event-driven principle of consultation
The libev event-driven principle of consultation

Time:09-23

Recent projects using libev event-driven library, found a very serious problem, I use process is as follows:
1. Create a known ev_timer, ev_signal watcher.
2. Add the various watcher to ev_type_start ();
3. Call ev_run () drive the entire event loop operation;

Next, in use process, there will be a new timing or other requirements, then will dynamically create new watcher ev_timer etc; But also call ev_type_start () will add watcher to have ev_run () up after the event loop, found that will not take effect immediately, must wait for the event loop after woke up the next event triggers, new watcher can be truly effective,

After internal source investigation, found epoll_ctl () function (under Linux system) in ev_poll. C epoll_modify () function calls, and in epoll_init initialization () :
 backend_mintime=1 e - 3;/* epoll does sometimes return early, this is just to get the worst */
Backend_modify=epoll_modify;
Backend_poll=epoll_poll;


Throughout the event loop, called backend_modify interface where only two:
 [study @ konishi libev] $grep 'backend_modify./nR 
-./ev. C: 2103: backend_modify (EV_A_ fd, anfd - & gt; Events, 0);
./ev. C: 2134: backend_modify (EV_A_ fd, o_events, anfd - & gt; Events);
./ev_epoll. C: 256: backend_modify=epoll_modify;
./ev_kqueue. C: 168: backend_modify=kqueue_modify;
./ev_poll. C: 135: backend_modify=poll_modify;
./ev_port. C: 159: backend_modify=port_modify;
./ev_select. C: 279: backend_modify=select_modify;
./ev_vars. H: 66: VAR (backend_modify, void (* backend_modify) (EV_P_ int fd, int gathering, int nev))
./ev_wrap. H: 15: # define backend_modify ((loop) - & gt; Backend_modify)
./ev_wrap. H: 114: # undef backend_modify


On ev. In c is called in 2103 and 2134, corresponding to ev. The static function in c fd_reify (), this function only in ev_run () is called once, the embed_prepare_cb () is called once, embed_prepare_cb () do not say, does not generally used,

The problem comes, we ev_run () in an event loop can only be called once, abnormal call many times make mistakes:
 test: ev. C: 3579: ev_run: an Assertion ` (" libev: ev_loop recursion during release detected ", ((loop) - & gt; Loop_done)!=0 x80) 'failed. 
Aborted (core dumped)


but new watcher of epoll mechanism cannot be implemented to add in, it will lead to add new events coming faster than eventloop watcher, so new watcher will not be able to real-time monitor the real !

I think the libev, libuv understanding is not deep, so strong and popular event store, can't not with that in mind, for such a big problem, so consult everybody how to use the libev, libuv for dynamic monitoring watcher/events?

CodePudding user response:

thank invited, but I don't understand this...

CodePudding user response:

Nobody answer? Oneself the top

CodePudding user response:

Didn't understand what you mean, just used epoll, used libeveent, epoll is certainly only add posts to the monitor, epoll_wait event will return, my understanding is that you are not the event handler processing time is too long, usually cannot long time processing function, if long suggested that write a queue, the queue handler to handle inside, the callback function as far as possible short, fast, and a number of time also shoulds not be too much,
  • Related