- 浏览: 969248 次
- 性别:
- 来自: 广州
最新评论
-
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 4158原文地址: http://haproxy.1wt.eu/10g ... -
Libevent 2.0.4-alpha released
2010-03-08 10:48 1611Libevent 2.0.4-alpha is now ava ... -
haproxy 1.4释出
2010-02-27 00:44 1371February 26th, 2010 : New stab ... -
haproxy 1.3.16 is getting closer !
2009-03-18 22:03 1542http://haproxy.1wt.eu/ Secon ... -
nmon 监视不错
2009-02-27 11:40 2646nmon 工具可以为 AIX 和 Linux 性能专家提供监视 ... -
我要改用libev?
2008-12-04 14:29 2936libev http://software.schmorp.d ... -
lighty2.0沙箱版本的协议和配置分析采用ragel 成功案例
2008-12-03 23:18 3171今天发现lighty2.0的 url, config, htt ... -
haproxy支持4层交换的规则了
2008-07-25 12:23 5058July 20th, 2008 : two lines... ... -
必备好用的网络工具socat Multipurpose relay (SOcket CAT)
2008-04-09 11:17 2984http://www.dest-unreach.org/soc ... -
赞!负载均衡器haproxy可以跑满10GBPS
2008-03-31 13:00 3001News, March 30th, 2008 I ... -
出了memcached分布式版本(repcached)的patch
2007-11-15 16:53 4037早上的时候arbow告诉我的。 名字叫repcached 主页 ... -
tcp的状态变迁和socket API
2007-10-17 13:57 3186做了这么多年的网络编程相信和大多数人对tcp的状态变迁不是很了 ... -
echo_server 200k并发
2007-10-17 13:56 2974在intel64位linux2.6.18上,erlang的ec ... -
ethtool包统计
2007-10-17 13:53 2969新版本的ethtool 可以统计到常见的包大小,这个不错 r ... -
mysql-proxy 千呼万唤才出来
2007-10-17 13:51 2656mysql出了个大家期待已久的mysql-proxy 作者就是 ... -
列出tcp连接情况
2007-10-17 12:35 1697看到命令不错 #! /bin/bash netstat -n ... -
我用的压力测试工具
2007-10-17 11:19 3098tsung : erlang编写的功能强劲 可以集群发动测试 ... -
Nginx Web服务器(转)
2007-10-10 21:57 6788感谢coderplayer同学, 让我转这篇文章。 N ... -
最近在研究几个流行的高性能web服务器 lighttpd nginx haproxy, 总结他们高...
2007-05-16 07:09 8681最近研究了几个流行的高性能web服务器 lighttpd ng ... -
总结下securecrt传文件的三种方式.1. scp scp [-1246BCpqrv...
2007-05-22 02:08 8721总结下securecrt传文件的三种方式. 1. scp ...
相关推荐
libevent 2.1.12版本,编译好的全部文件,包含lib和头文件
libevent的debug版本的lib库
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: ...
libevent参考手册(中文版),包含libevent的设计说明、原理描述,模块介绍和接口说明。
最新的libevent中文参考手册; Libevent 是用于编写高速可移植非阻塞 IO 应用的库,其设计目标是: 可移植性:使用 libevent 编写的程序应该可以在 libevent 支持的所有平台上工作。即使 没有好的方式进行非阻塞 IO...
c++版本libevent,仿照libevent写的一个服务器框架,libevent的基本功能已实现,暂时不能在windows平台上使用,定时器是纯粹的timer wheel方式,与libevent的小根堆不一样,而且最大定时时间是固定的,暂时不支持...
libevent-2.0.21-stable windows编译好的版本,内含libevent.lib、libevent_core.lib、libevent_extras.lib
提供两个libevent的版本 libevent-1.4.9-stable.zip(包含中文注释) libevent-1.4.12-stable.tar.gz(例子使用的版本)
libevent book 必备参考资料,方便学习libevent网络库
libevent在windows下编译的的core,extra,lib三个文件2.1版本
为方便阅读,把blog上的libevent源码深度剖析系列文章整合成一个pdf。
基于libevent 1.4.13版本实现的多线程网络通信模块,系统测试表现良好,可以通过阅读libevent源码加深理解,希望对大家有用。
vs2008编译的libevent项目,根据源代码中makefile.nmake创建,用于调试 libevent版本:libevent-2.0.22
libevent-2.1.10-stable.tar libevent-release-1.4.15-stable.tar libevent文件组织 用50个金币买的,不想让继续多赚 包含这些
libevent库,文字版,很清晰,附带libevent参考手册(中文版) libevent源码深度剖析,根据libevent开源代码框架进行剖析,很不错值得学习借鉴,还有libevent中C语言的功底值得学习揣摩!
Libevent 编程中文帮助文档 版本:V1.0 日期:2016-11-15 作者:周勇 本文 档是 2009-2012 年由 Nick-Mathewson 基于 Attribution-Noncommercial-Share Alike 许可协议 3.0 创建,未来版本将会使用约束性更低的...
libevent的动态库(dll)版本,提取了所有函数导出的。 包含32和64位版本 libevent_core.dll对应core版本 libevent_extra.dll对应extra版本,是core版本的超集
最新libevent
libevent源码深度解析
libevent官方手册,使用者可以根据查看