libev官方手册：高性能事件处理与网络库详解

5星 · 超过95%的资源需积分: 45 190 浏览量更新于2024-07-20 1 收藏 611KB PDF 举报

libev官方手册是一份详尽的指南，介绍了一款高效、轻量级的事件循环和事件模型网络库。libev在设计上旨在提供更快的速度、较少的bug、丰富的特性和更小的体积，是对先前lievent和Event Perl模块的改进。该文档主要分为以下几个部分： 1. **名称和简介**： libev的全称未在标题中给出，但可以推测这是一个专注于事件处理和I/O操作的库，适合高性能网络应用，如服务器端程序。 2. **简要示例**：提供了一个示例程序，展示了如何在libev环境中设置和管理事件。这可能是为了帮助初学者快速上手。 3. **文档结构**：文档结构清晰，包括一个索引，便于查找特定主题。读者可以快速找到关于定时器、错误处理、事件循环控制等关键部分的信息。 4. **功能特点**： - **高性能**：强调了libev在性能方面的优势，比如快速事件处理和响应。 - **稳定性**：bug更少，表明库的可靠性和健壮性。 - **功能丰富**：除了基本的I/O事件外，可能还支持定时器、周期任务、信号处理等高级功能。 - **代码简洁**：体积小意味着代码量较少，易于维护。 5. **常见问题与解决方案**： - **文件描述符问题**：讨论了特殊情况下，如文件描述符消失、复制、文件处理、子进程继承等问题及其处理方法。 - **时间管理**：提醒开发者注意相对定时器、过早触发、时钟同步等问题。 - **信号处理**：强调信号处理函数的正确使用，尤其是在子进程环境中的信号继承问题。 6. **Watcher类型与功能**： - **ev_io**：专用于检测文件描述符的读写状态，以及针对特殊问题的处理。 - **ev_timer**：支持相对和重复定时，涉及精确性、时钟同步和动画暂停的问题。 - **ev_periodic**：可能是定期执行的任务调度，讨论了是否启用cron-like任务。 - **ev_signal**：处理各种信号，关注信号传递的继承问题。 7. **示例和数据成员**：文档提供了各种watcher类型的实例代码，帮助读者理解如何在实际项目中使用这些功能。 libev官方手册是一份全面的指南，涵盖了库的各个方面，无论是基础的事件监听还是复杂的高级功能，都有详细的解释和示例，有助于开发者充分利用libev提升应用程序的性能和可靠性。

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.

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

第15页共87页 2017/6/12 上午9:34

... 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!

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.

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

第16页共87页 2017/6/12 上午9:34

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 iterations/wake-ups is to use

ev_periodic watchers and make sure they fire on, say, one-second boundaries only.

Example: we only need 0.1s timeout granularity, and we wish not to poll more often

than 100 times per second:

ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1);

ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);

ev_invoke_pending (loop)

This call will simply invoke all pending watchers while resetting their pending state.

Normally, ev_run does this automatically when required, but when overriding the

invoke callback this call comes handy. This function can be invoked from a watcher -

this can be useful for example when you want to do some lengthy calculation and

want to pass further event handling to another thread (you still have to make sure

only one thread executes within ev_invoke_pending or ev_run of course).

int ev_pending_count (loop)

Returns the number of pending watchers - zero indicates that no watchers are

pending.

ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P))

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

第17页共87页 2017/6/12 上午9:34

This overrides the invoke pending functionality of the loop: Instead of invoking all

pending watchers when there are any, ev_run will call this callback instead. This is

useful, for example, when you want to invoke the actual watchers inside another

context (another thread etc.).

If you want to reset the callback, use ev_invoke_pending as new callback.

ev_set_loop_release_cb (loop, void (*release)(EV_P) throw (), void (*acquire)

(EV_P) throw ())

Sometimes you want to share the same loop between multiple threads. This can be

done relatively simply by putting mutex_lock/unlock calls around each call to a libev

function.

However, ev_run can run an indefinite time, so it is not feasible to wait for it to return.

One way around this is to wake up the event loop via ev_break and ev_async_send,

another way is to set these release and acquire callbacks on the loop.

When set, then release will be called just before the thread is suspended waiting for

new events, and acquire is called just afterwards.

Ideally, release will just call your mutex_unlock function, and acquire will just call the

mutex_lock function again.

While event loop modifications are allowed between invocations of release and acquire

(that's their only purpose after all), no modifications done will affect the event loop,

i.e. adding watchers will have no effect on the set of file descriptors being watched,

or the time waited. Use an ev_async watcher to wake up ev_run when you want it to

take note of any changes you made.

In theory, threads executing ev_run will be async-cancel safe between invocations of

release and acquire.

See also the locking example in the THREADS section later in this document.

ev_set_userdata (loop, void *data)

void *ev_userdata (loop)

Set and retrieve a single void * associated with a loop. When ev_set_userdata has

never been called, then ev_userdata returns 0.

These two functions can be used to associate arbitrary data with a loop, and are

intended solely for the invoke_pending_cb, release and acquire callbacks described

above, but of course can be (ab-)used for any other purpose as well.

ev_verify (loop)

This function only does something when EV_VERIFY support has been compiled in,

which is the default for non-minimal builds. It tries to go through all internal

structures and checks them for validity. If anything is found to be inconsistent, it will

print an error message to standard error and call abort ().

This can be used to catch bugs inside libev itself: under normal circumstances, this

function will never abort as of course libev keeps its data structures consistent.

ANATOMY OF A WATCHER

In the following description, uppercase TYPE in names stands for the watcher type, e.g.

ev_TYPE_start can mean ev_timer_start for timer watchers and ev_io_start for I/O watchers.

A watcher is an opaque structure that you allocate and register to record your interest in some

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

第18页共87页 2017/6/12 上午9:34

剩余86页未读，继续阅读

轮子学长

粉丝: 264
资源: 16

libev官方手册：高性能事件处理与网络库详解

libev 手册 libev 分析

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

libev手册

libev(aarch-64) = 4.15-3.el7 is needed by libev-devel-4.15-3.el7.aarch64

下载libev-4.15-3.el7.x86_64.rpm

libev 中文手册

ERROR: Could not build wheels for gevent, which is required to install pyproject.toml-based projects

linux下如何配置libev库并成功运行

libev 安装 linux

libev与libevent的比较

最新资源

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