libevent的主干版本把ET加进去了
老朱说 libevent的主干版本把ET加进去了,Valery Kholodkov今年5月底提交了个patch.
大家的福分哦。
http://www.mail-archive.com/[email protected]/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
[email protected]
http://monkeymail.org/mailman/listinfo/libevent-users
大家的福分哦。
http://www.mail-archive.com/[email protected]/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
[email protected]
http://monkeymail.org/mailman/listinfo/libevent-users