>>>>> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
JNP> On Thu, 2005-03-24 at 12:20 +0100, [EMAIL PROTECTED] wrote: >> I extended unix.c to one additional mechanism (/dev/poll). >> According to available benchmarks this mechanism has >> much better performance as select or poll. I tested it only >> on Solaris. Do you think it would be a good idea to add >> the changes to cpan.org? What should be done to do that? JNP> Wow, cool! JNP> Email a "diff -u" patch to me or to [EMAIL PROTECTED] what would be really extra cool would be support for libevent. it is a c library wrapper around several different core event loop technologies (including /dev/poll) but with the wrapper providing a single public api. it provides a method to select which core event loop to use or it will pick one. so by adding this to event.pm, we would pick up more loop styles with one wrapper. from http://www.monkey.org/~provos/libevent/: Currently, libevent supports /dev/poll, kqueue(2), select(2), poll(2) and epoll(4). It also has experimental support for real-time signals. The internal event mechanism is completely independent of the exposed event API, and a simple update of libevent can provide new functionality without having to redesign the applications. As a result, Libevent allows for portable application development and provides the most scalable event notification mechanism available on an operating system. and there is a win32 port of it now: http://www.datanerds.net/~mike/libevent.html wrapping this under event.pm would be a major win IMO. i had wanted it in its own perl module but there is no reason to not put it under event.pm as that would mean less work at the perl level to support as we all have support for event.pm's api. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
