- 浏览: 981805 次
- 性别:
- 来自: 广州
最新评论
-
qingchuwudi:
有用,非常感谢!
erlang进程的优先级 -
zfjdiamond:
你好 这条命令 在那里输入??
你们有yum 我有LuaRocks -
simsunny22:
这个是在linux下运行的吧,在window下怎么运行escr ...
escript的高级特性 -
mozhenghua:
http://www.erlang.org/doc/apps/ ...
mnesia 分布协调的几个细节 -
fxltsbl:
A new record of 108000 HTTP req ...
Haproxy 1.4-dev2: barrier of 100k HTTP req/s crossed
老朱说 libevent的主干版本把ET加进去了,Valery Kholodkov今年5月底提交了个patch.
大家的福分哦。
http://www.mail-archive.com/libevent-users@monkey.org/msg01151.html
[Libevent-users] Support for Edge-Triggered behaviour
Valery Kholodkov
Thu, 29 May 2008 08:41:45 -0700
Greetings!
Since discovering libevent for myself I've been wondering
why where is still no support for Edge-Triggered behaviour, which
from my point of view could be easily implemented.
There were many talks already among Linux kernel developers
as well as application developers about how and why to use
it. I have also discovered that people already were trying to
implement such functionality with greater or lesser degree of
success, e.g. here:
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2005-August/000367.html
So I tried to do it once again and a link to a patch is given below.
But the problem with Edge-Triggered behaviour is that few people
understand it. There is simply no clear understanding among
application developers of how Edge-Triggered works, which
produces Fear, Uncertainity and Doubt (FUD). Therefore I think
I have to provide some guidelines about this.
libevent is currently by default Level-Triggered (LT), this means
that an event is generated every time kqueue/epoll/select/whatever
is invoked and a descriptor has data available to read or IO space
available to write to.
With Edge-Triggered (ET) behaviour an event is generated every time
the amount of data available to read overcomes threshold of 0
or the amount of IO space available to write to overcomes
threshold of 0.
This means that no new events will be generated unless the
application will read out all available incoming data or fill
all available outbound IO space.
This means that whenever a descriptor available to read is reported
and Edge-Triggered behaviour takes place the application have to read
out all the data until EOF or error or EAGAIN will be returned by
read/readv. In the similar way whenever a descriptor available to
write is reported and Edge-Triggered behaviour takes place the
application have to write all the data it has until an error or EAGAIN
will be returned by write/writev/sendfile.
Such a strategy is also recommended by select_tut(2) man page
(see section SELECT LAW point 6) to prevent IO starvation. So
there is nothing mystical behind it and similar strategy has
been already existing in pre-ET era.
This has a significant advantage, that whenever you read and
you run out of destination buffer/IO space there is no need
to unarm the descriptor by calling event_del, you just have
to remember somewhere that the descriptor is still available
to read. Then you return to it when the destination buffer/IO
space emerges.
In the similar way where is not need to rearm the descriptor
whenever data emerges to be sent out. You just have to remember
in your application that the descriptor was available to write
and simply continue to write.
With epoll/kqueue this saves you a number of system calls which is
the source of additional performance.
With kqueue Edge-Triggered behaviour could be simply enforced using
EV_CLEAR flag according to this message:
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/0547.html
The patch itself is submitted into SF's patch tracking system:
http://sourceforge.net/tracker/index.php?func=detail&aid=1968284&group_id=50884&atid=461324
This patch introduces EV_ET flag. Whenever you specify EV_ET in event_set
call a specific module will try enforce Edge-Triggered behaviour.
Whevever Edge-Triggered behaviour takes place ,the event argument of a
callback will additionally contain EV_ET flag, and you should react
accordingly. When methods are used, which do not support ET such as
select or poll, no EV_ET flag will be ever set.
The file test/test_et.c demonstrates the usage of EV_ET flag.
I hope that maintainers will agree to integrate the patch in future
versions of libevent.
Good luck and additional performance to your applications!
--
Best regards,
Valery Kholodkov
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
大家的福分哦。
http://www.mail-archive.com/libevent-users@monkey.org/msg01151.html
[Libevent-users] Support for Edge-Triggered behaviour
Valery Kholodkov
Thu, 29 May 2008 08:41:45 -0700
Greetings!
Since discovering libevent for myself I've been wondering
why where is still no support for Edge-Triggered behaviour, which
from my point of view could be easily implemented.
There were many talks already among Linux kernel developers
as well as application developers about how and why to use
it. I have also discovered that people already were trying to
implement such functionality with greater or lesser degree of
success, e.g. here:
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2005-August/000367.html
So I tried to do it once again and a link to a patch is given below.
But the problem with Edge-Triggered behaviour is that few people
understand it. There is simply no clear understanding among
application developers of how Edge-Triggered works, which
produces Fear, Uncertainity and Doubt (FUD). Therefore I think
I have to provide some guidelines about this.
libevent is currently by default Level-Triggered (LT), this means
that an event is generated every time kqueue/epoll/select/whatever
is invoked and a descriptor has data available to read or IO space
available to write to.
With Edge-Triggered (ET) behaviour an event is generated every time
the amount of data available to read overcomes threshold of 0
or the amount of IO space available to write to overcomes
threshold of 0.
This means that no new events will be generated unless the
application will read out all available incoming data or fill
all available outbound IO space.
This means that whenever a descriptor available to read is reported
and Edge-Triggered behaviour takes place the application have to read
out all the data until EOF or error or EAGAIN will be returned by
read/readv. In the similar way whenever a descriptor available to
write is reported and Edge-Triggered behaviour takes place the
application have to write all the data it has until an error or EAGAIN
will be returned by write/writev/sendfile.
Such a strategy is also recommended by select_tut(2) man page
(see section SELECT LAW point 6) to prevent IO starvation. So
there is nothing mystical behind it and similar strategy has
been already existing in pre-ET era.
This has a significant advantage, that whenever you read and
you run out of destination buffer/IO space there is no need
to unarm the descriptor by calling event_del, you just have
to remember somewhere that the descriptor is still available
to read. Then you return to it when the destination buffer/IO
space emerges.
In the similar way where is not need to rearm the descriptor
whenever data emerges to be sent out. You just have to remember
in your application that the descriptor was available to write
and simply continue to write.
With epoll/kqueue this saves you a number of system calls which is
the source of additional performance.
With kqueue Edge-Triggered behaviour could be simply enforced using
EV_CLEAR flag according to this message:
http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/0547.html
The patch itself is submitted into SF's patch tracking system:
http://sourceforge.net/tracker/index.php?func=detail&aid=1968284&group_id=50884&atid=461324
This patch introduces EV_ET flag. Whenever you specify EV_ET in event_set
call a specific module will try enforce Edge-Triggered behaviour.
Whevever Edge-Triggered behaviour takes place ,the event argument of a
callback will additionally contain EV_ET flag, and you should react
accordingly. When methods are used, which do not support ET such as
select or poll, no EV_ET flag will be ever set.
The file test/test_et.c demonstrates the usage of EV_ET flag.
I hope that maintainers will agree to integrate the patch in future
versions of libevent.
Good luck and additional performance to your applications!
--
Best regards,
Valery Kholodkov
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
发表评论
-
Haproxy 1.4-dev2: barrier of 100k HTTP req/s crossed
2010-03-09 23:00 4221原文地址: http://haproxy.1wt.eu/10g ... -
Libevent 2.0.4-alpha released
2010-03-08 10:48 1675Libevent 2.0.4-alpha is now ava ... -
haproxy 1.4释出
2010-02-27 00:44 1413February 26th, 2010 : New stab ... -
haproxy 1.3.16 is getting closer !
2009-03-18 22:03 1588http://haproxy.1wt.eu/ Secon ... -
nmon 监视不错
2009-02-27 11:40 2677nmon 工具可以为 AIX 和 Linux 性能专家提供监视 ... -
我要改用libev?
2008-12-04 14:29 2970libev http://software.schmorp.d ... -
lighty2.0沙箱版本的协议和配置分析采用ragel 成功案例
2008-12-03 23:18 3215今天发现lighty2.0的 url, config, htt ... -
haproxy支持4层交换的规则了
2008-07-25 12:23 5108July 20th, 2008 : two lines... ... -
必备好用的网络工具socat Multipurpose relay (SOcket CAT)
2008-04-09 11:17 3030http://www.dest-unreach.org/soc ... -
赞!负载均衡器haproxy可以跑满10GBPS
2008-03-31 13:00 3042News, March 30th, 2008 I ... -
出了memcached分布式版本(repcached)的patch
2007-11-15 16:53 4081早上的时候arbow告诉我的。 名字叫repcached 主页 ... -
tcp的状态变迁和socket API
2007-10-17 13:57 3241做了这么多年的网络编程相信和大多数人对tcp的状态变迁不是很了 ... -
echo_server 200k并发
2007-10-17 13:56 3025在intel64位linux2.6.18上,erlang的ec ... -
ethtool包统计
2007-10-17 13:53 3035新版本的ethtool 可以统计到常见的包大小,这个不错 r ... -
mysql-proxy 千呼万唤才出来
2007-10-17 13:51 2688mysql出了个大家期待已久的mysql-proxy 作者就是 ... -
列出tcp连接情况
2007-10-17 12:35 1757看到命令不错 #! /bin/bash netstat -n ... -
我用的压力测试工具
2007-10-17 11:19 3150tsung : erlang编写的功能强劲 可以集群发动测试 ... -
Nginx Web服务器(转)
2007-10-10 21:57 6887感谢coderplayer同学, 让我转这篇文章。 N ... -
最近在研究几个流行的高性能web服务器 lighttpd nginx haproxy, 总结他们高...
2007-05-16 07:09 8744最近研究了几个流行的高性能web服务器 lighttpd ng ... -
总结下securecrt传文件的三种方式.1. scp scp [-1246BCpqrv...
2007-05-22 02:08 8768总结下securecrt传文件的三种方式. 1. scp ...
相关推荐
**libevent 2.1.12版本详解** Libevent是一个高性能、轻量级的事件通知库,广泛用于网络编程,特别是在服务器端开发中。它提供了异步事件处理的能力,可以高效地处理大量并发连接,使得开发者能够编写出高并发、低...
c++版本libevent,仿照libevent写的一个服务器框架,libevent的基本功能已实现,暂时不能在windows平台上使用,定时器是纯粹的timer wheel方式,与libevent的小根堆不一样,而且最大定时时间是固定的,暂时不支持...
描述"libevent的debug版本的lib库"进一步强调了这是libevent库的调试版本,意味着它包含了用于调试的特殊标志和配置,比如未初始化的变量检测、更严格的内存管理以及可能的调试输出等功能。 **libevent库介绍** ...
"libevent-2.1.12-android-arm64-arm-v7a.7z" 是一个针对Android平台的libevent库的压缩文件,版本为2.1.12,这是2020年的一个稳定版本。文件格式为.7z,意味着它是用7-Zip软件进行压缩的,这种格式通常能提供较高的...
在版本状态方面,需要注意的是,不同版本的libevent可能在某些API上存在差异,因此,在使用时需要确保程序与所使用的libevent版本兼容。 手册接着描述了如何设置libevent。在这一部分,会讲解如何处理libevent中的...
总的来说,"android-libevent2"是一个针对Android优化的libevent库版本,提供了源码和编译好的库文件,便于开发者集成到自己的Android项目中。如果项目需要处理大量的网络事件或需要安全的加密通信,libevent2结合...
libevent-devel-1.4.13-4.el6.x86_64: failure: Packages/libevent-devel-1.4.13-4.el6.x86_64.rpm from c6-media: [Errno 256] No more mirrors to try. libevent-headers-1.4.13-4.el6.noarch: failure: ...
“Windows下libevent的lib库2.1版本”指的是libevent这个开源事件通知库在Windows操作系统上的一个特定版本——2.1版,主要关注的是库文件部分,特别是lib文件格式,用于链接到其他应用程序以实现异步事件驱动的网络...
为方便阅读,把blog上的libevent源码深度剖析系列文章整合成一个pdf。
3. **libevent**:这是一个历史遗留的库,包含了libevent_core和libevent_extra的所有功能,但未来的版本可能会移除这个库,因此建议直接使用libevent_core和libevent_extra。 此外,在某些平台上还会额外安装: 1...
libevent 2.1.5版本中,对于一些早期版本的event_base函数已经标记为废弃。 与事件循环一起工作涉及到运行事件循环、停止事件循环、重新检查events、检查内部时间缓存等操作。事件循环的运行和停止是事件驱动程序的...
在本资源中,我们关注的是使用Visual Studio 2015(VS2015)编译的libevent,版本为2.1.10。这个版本包含了头文件和库文件,是将libevent集成到Windows平台上的VS项目中的基础。 首先,我们来理解一下`libevent`的...
这对于开发者来说非常方便,他们可以快速构建项目,进行代码调试,以理解Libevent的工作原理或者定制自己的版本。 **libevent核心知识点** 1. **事件模型**:Libevent提供了一种跨平台的方式来处理各种事件,如...
标题中的"libevent(2.1.8)库及头文件文件"指的是一个开源的事件通知库——Libevent的特定版本,即2.1.8稳定版。这个库提供了异步网络I/O和时间事件处理的能力,广泛应用于服务器端的开发,如HTTP服务器、DNS解析器...
libevent-devel-2.0.21-4.el7.x86_64.rpm这个包就是针对CentOS 7系统的一个特定版本,其中"2.0.21"代表libevent的版本号,"4"表示这个特定发行版的更新次数,"el7"是对应于CentOS 7的代号,"x86_64"则表示该包是为64...
在这个libevent-2.0.21-stable版本中,专为Windows平台进行了编译优化,包含了一些关键的库文件,如libevent.lib、libevent_core.lib以及libevent_extras.lib,这些库文件是开发人员在Windows系统上利用libevent进行...
标题"可供调试的vs2013版本libevent"指出这是一个针对Visual Studio 2013(VS2013)编译环境的libevent库,特别强调了它适用于调试目的。libevent是一个开源的事件通知库,常用于编写高性能、异步、非阻塞式的网络...
对于旧版本libevent的支持,libevent 2.0之后的版本对API进行了优化,建议新项目使用最新版本。如果需要向后兼容,可以使用旧的头文件,但要注意旧版本可能不支持多线程和一些新的特性。 总的来说,libevent 提供了...
Libevent 2.0.21版本SDK的CHM格式帮助文档,同管网显示效果相同,省去GOOGLE API的烦劳。
libevent2是libevent的第二个主要版本,带来了许多改进和新特性,旨在提高性能和易用性。 1. **事件模型** Libevent的核心是其事件模型,它基于一种非阻塞I/O模型。这种模型允许程序在等待I/O操作完成时继续执行...