libev：高性能事件循环库文档详解

需积分: 44 161 浏览量更新于2024-07-16 收藏 3.06MB PDF 举报

"libev文档.pdf" Libev是一个用C语言编写的高性能、功能丰富的事件循环库，适用于Linux系统，并且支持epoll等机制。它与libevent等其他事件库相比，提供了更强大的性能和更多元化的特性。文档旨在详细介绍libev的使用和设计原理，但假设读者已具备基于事件的编程基础。在libev库中，事件循环是程序的核心，它负责监控和响应各种事件，如文件描述符的读写就绪、定时器事件以及信号事件。文档首先提供了一个快速概览，帮助用户迅速了解libev的主要功能和工作方式。文档的"FEATURES"部分列举了libev的关键特性，可能包括高效的数据结构、对多种事件源的支持（如epoll、kqueue、poll和select）以及灵活的事件处理模型。此外，libev还具有良好的跨平台兼容性，可以在Unix-like系统上运行。在"CONVENTIONS"章节，文档会阐述libev中的一些约定和术语，比如如何表示时间、错误处理机制等。"TIMEREPRESENTATION"讨论了libev如何表示和处理时间，包括精度、时区和时间更新的问题。 "GLOBALFUNCTIONS"和"FUNCTIONSCONTROLLINGEVENTLOOPS"部分则详细介绍了用于初始化、控制和停止事件循环的函数，以及如何注册和取消事件监听器（watchers）。"ANATOMYOFAWATCHER"解释了watcher对象的结构和状态，包括它们的生命周期和优先级模型。文档深入探讨了不同类型的watchers，如"ev_io"用于处理文件描述符的读写事件，特别强调了在文件描述符消失、复制、关闭、进程fork、SIGPIPE信号处理以及accept操作受限时的特殊处理。"ev_timer"是用于设置相对或重复超时的watcher，文档指出如何智能地设定超时以避免过早触发或时间更新问题。"ev_periodic"则用于周期性任务，它可以模拟cron定时任务，文档会讨论其灵活性和使用场景。 "ev_signal"watcher用于监听和处理信号事件，比如当接收到特定信号时执行回调。文档中还提供了各种示例代码，以帮助开发者更好地理解和应用这些功能。 libev文档是学习和使用libev库的重要参考资料，它详尽地解释了库的各个方面，对于希望利用libev构建高性能、低延迟的异步服务的开发者来说非常有价值。通过深入理解并实践文档中的内容，开发者能够充分利用libev的优势，创建出高效、稳定的事件驱动程序。

2020/1/2 libev

pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod 11/64

static void

post_fork_child (void)

{

ev_loop_fork (EV_DEFAULT);

}

...

pthread_atfork (0, 0, post_fork_child);

int ev_is_default_loop (loop)

Returns true when the given loop is, in fact, the default loop, and false otherwise.

unsigned int ev_iteration (loop)

Returns the current iteration count for the event loop, which is identical to the number of times libev did

poll for new events. It starts at 0 and happily wraps around with enough iterations.

This value can sometimes be useful as a generation counter of sorts (it "ticks" the number of loop

iterations), as it roughly corresponds with ev_prepare and ev_check calls - and is incremented between

the prepare and check phases.

unsigned int ev_depth (loop)

Returns the number of times ev_run was entered minus the number of times ev_run was exited normally,

in other words, the recursion depth.

Outside ev_run, this number is zero. In a callback, this number is 1, unless ev_run was invoked

recursively (or from another thread), in which case it is higher.

Leaving ev_run abnormally (setjmp/longjmp, cancelling the thread, throwing an exception etc.), doesn't

count as "exit" - consider this as a hint to avoid such ungentleman-like behaviour unless it's really

convenient, in which case it is fully supported.

unsigned int ev_backend (loop)

Returns one of the EVBACKEND_* flags indicating the event backend in use.

ev_tstamp ev_now (loop)

Returns the current "event loop time", which is the time the event loop received events and started

processing them. This timestamp does not change as long as callbacks are being processed, and this is

also the base time used for relative timers. You can treat it as the timestamp of the event occurring (or

more correctly, libev finding out about it).

ev_now_update (loop)

Establishes the current time by querying the kernel, updating the time returned by ev_now () in the

progress. This is a costly operation and is usually done automatically within ev_run ().

This function is rarely useful, but when some event callback runs for a very long time without entering the

event loop, updating libev's idea of the current time is a good idea.

See also The special problem of time updates in the ev_timer section.

ev_suspend (loop)

ev_resume (loop)

These two functions suspend and resume an event loop, for use when the loop is not used for a while and

timeouts should not be processed.

A typical use case would be an interactive program such as a game: When the user presses ^Z to suspend

the game and resumes it an hour later it would be best to handle timeouts as if no time had actually

passed while the program was suspended. This can be achieved by calling ev_suspend in your SIGTSTP

handler, sending yourself a SIGSTOP and calling ev_resume directly afterwards to resume timer processing.

Effectively, all ev_timer watchers will be delayed by the time spend between ev_suspend and ev_resume,

and all ev_periodic watchers will be rescheduled (that is, they will lose any events that would have

occurred while suspended).

After calling ev_suspend you must not call any function on the given loop other than ev_resume, and you

must not call ev_resume without a previous call to ev_suspend.

Calling ev_suspend/ev_resume has the side effect of updating the event loop time (see ev_now_update).

bool ev_run (loop, int flags)

2020/1/2 libev

pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod 12/64

Finally, this is it, the event handler. This function usually is called after you have initialised all your

watchers and you want to start handling events. It will ask the operating system for any new events, call

the watcher callbacks, and then repeat the whole process indefinitely: This is why event loops are called

loops.

If the flags argument is specified as 0, it will keep handling events until either no event watchers are active

anymore or ev_break was called.

The return value is false if there are no more active watchers (which usually means "all jobs done" or

"deadlock"), and true in all other cases (which usually means " you should call ev_run again").

Please note that an explicit ev_break is usually better than relying on all watchers to be stopped when

deciding when a program has finished (especially in interactive programs), but having a program that

automatically loops as long as it has to and no longer by virtue of relying on its watchers stopping

correctly, that is truly a thing of beauty.

This function is mostly exception-safe - you can break out of a ev_run call by calling longjmp in a callback,

throwing a C++ exception and so on. This does not decrement the ev_depth value, nor will it clear any

outstanding EVBREAK_ONE breaks.

A flags value of EVRUN_NOWAIT will look for new events, will handle those events and any already

outstanding ones, but will not wait and block your process in case there are no events and will return after

one iteration of the loop. This is sometimes useful to poll and handle new events while doing lengthy

calculations, to keep the program responsive.

A flags value of EVRUN_ONCE will look for new events (waiting if necessary) and will handle those and any

already outstanding ones. It will block your process until at least one new event arrives (which could be an

event internal to libev itself, so there is no guarantee that a user-registered callback will be called), and

will return after one iteration of the loop.

This is useful if you are waiting for some external event in conjunction with something not expressible

using other libev watchers (i.e. "roll your own ev_run"). However, a pair of ev_prepare/ev_check

watchers is usually a better approach for this kind of thing.

Here are the gory details of what ev_run does (this is for your understanding, not a guarantee that things

will work exactly like this in future versions):

- Increment loop depth.

- Reset the ev_break status.

- Before the first iteration, call any pending watchers.

LOOP:

- If EVFLAG_FORKCHECK was used, check for a fork.

- If a fork was detected (by any means), queue and call all fork watchers.

- Queue and call all prepare watchers.

- If ev_break was called, goto FINISH.

- If we have been forked, detach and recreate the kernel state

as to not disturb the other process.

- Update the kernel state with all outstanding changes.

- Update the "event loop time" (ev_now ()).

- Calculate for how long to sleep or block, if at all

(active idle watchers, EVRUN_NOWAIT or not having

any active watchers at all will result in not sleeping).

- Sleep if the I/O and timer collect interval say so.

- Increment loop iteration counter.

- Block the process, waiting for any events.

- Queue all outstanding I/O (fd) events.

- Update the "event loop time" (ev_now ()), and do time jump adjustments.

- Queue all expired timers.

- Queue all expired periodics.

- Queue all idle watchers with priority higher than that of pending events.

- Queue all check watchers.

- Call all queued watchers in reverse order (i.e. check watchers first).

Signals and child watchers are implemented as I/O watchers, and will

be handled here by queueing them when their watcher gets executed.

- If ev_break has been called, or EVRUN_ONCE or EVRUN_NOWAIT

were used, or there are no active watchers, goto FINISH, otherwise

continue with step LOOP.

FINISH:

- Reset the ev_break status iff it was EVBREAK_ONE.

- Decrement the loop depth.

- Return.

Example: Queue some jobs and then loop until no events are outstanding anymore.

... queue jobs here, make sure they register event watchers as long

... as they still have work to do (even an idle watcher will do..)

ev_run (my_loop, 0);

... jobs done or somebody called break. yeah!

2020/1/2 libev

pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod 13/64

ev_break (loop, how)

Can be used to make a call to ev_run return early (but only after it has processed all outstanding events).

The how argument must be either EVBREAK_ONE, which will make the innermost ev_run call return, or

EVBREAK_ALL, which will make all nested ev_run calls return.

This "break state" will be cleared on the next call to ev_run.

It is safe to call ev_break from outside any ev_run calls, too, in which case it will have no effect.

ev_ref (loop)

ev_unref (loop)

Ref/unref can be used to add or remove a reference count on the event loop: Every watcher keeps one

reference, and as long as the reference count is nonzero, ev_run will not return on its own.

This is useful when you have a watcher that you never intend to unregister, but that nevertheless should

not keep ev_run from returning. In such a case, call ev_unref after starting, and ev_ref before stopping

it.

As an example, libev itself uses this for its internal signal pipe: It is not visible to the libev user and should

not keep ev_run from exiting if no event watchers registered by it are active. It is also an excellent way to

do this for generic recurring timers or from within third-party libraries. Just remember to unref after start

and ref before stop (but only if the watcher wasn't active before, or was active before, respectively. Note

also that libev might stop watchers itself (e.g. non-repeating timers) in which case you have to ev_ref in

the callback).

Example: Create a signal watcher, but keep it from keeping ev_run running when nothing else is active.

ev_signal exitsig;

ev_signal_init (&exitsig, sig_cb, SIGINT);

ev_signal_start (loop, &exitsig);

ev_unref (loop);

Example: For some weird reason, unregister the above signal handler again.

ev_ref (loop);

ev_signal_stop (loop, &exitsig);

ev_set_io_collect_interval (loop, ev_tstamp interval)

ev_set_timeout_collect_interval (loop, ev_tstamp interval)

These advanced functions influence the time that libev will spend waiting for events. Both time intervals

are by default 0, meaning that libev will try to invoke timer/periodic callbacks and I/O callbacks with

minimum latency.

Setting these to a higher value (the interval must be >= 0) allows libev to delay invocation of I/O and

timer/periodic callbacks to increase efficiency of loop iterations (or to increase power-saving

opportunities).

The idea is that sometimes your program runs just fast enough to handle one (or very few) event(s) per

loop iteration. While this makes the program responsive, it also wastes a lot of CPU time to poll for new

events, especially with backends like select () which have a high overhead for the actual polling but can

deliver many events at once.

By setting a higher io collect interval you allow libev to spend more time collecting I/O events, so you can

handle more events per iteration, at the cost of increasing latency. Timeouts (both ev_periodic and

ev_timer) will not be affected. Setting this to a non-null value will introduce an additional ev_sleep ()

call into most loop iterations. The sleep time ensures that libev will not poll for I/O events more often then

once per this interval, on average (as long as the host time resolution is good enough).

Likewise, by setting a higher timeout collect interval you allow libev to spend more time collecting

timeouts, at the expense of increased latency/jitter/inexactness (the watcher callback will be called later).

ev_io watchers will not be affected. Setting this to a non-null value will not introduce any overhead in

libev.

Many (busy) programs can usually benefit by setting the I/O collect interval to a value near 0.1 or so,

which is often enough for interactive servers (of course not for games), likewise for timeouts. It usually

doesn't make much sense to set it to a lower value than 0.01, as this approaches the timing granularity of

most systems. Note that if you do transactions with the outside world and you can't increase the

parallelity, then this setting will limit your transaction rate (if you need to poll once per transaction and the

I/O collect interval is 0.01, then you can't do more than 100 transactions per second).

Setting the timeout collect interval can improve the opportunity for saving power, as the program will

"bundle" timer callback invocations that are "near" in time together, by delaying some, thus reducing the

number of times the process sleeps and wakes up again. Another useful technique to reduce

剩余63页未读，继续阅读

wh653

粉丝: 1
资源: 5

libev：高性能事件循环库文档详解

高性能网络库——libev手册

libev-官方手册

libev手册及常用监听器讲解及实例

mongols 文档手册.pdf

nodeJS.pdf

Gevent指南.pdf

libuv中文教程.pdf

libev 中文手册（只有一小部分是中文，酌情下载）

Linux高性能服务器编程源码,linux高性能服务器编程pdf,CC++源码.zip.zip

Node.js设计与使用详解

最新资源

libev　中文手册（只有一小部分是中文，酌情下载）