Rocco, How do you prefer to receive patches? diff -u?
Anyway, here are fixes for 2 typos in Wheel.pm... @@ -115,7 +115,7 @@ =head1 STATIC FUNCTIONS -These functions keep global information about all weels. They should +These functions keep global information about all wheels. They should be called as normal functions: &POE::Wheel::function( ... ); @@ -124,7 +124,7 @@ =item allocate_wheel_id -allocate_wheel_id() allocates a uniquely identifier for a wheel. +allocate_wheel_id() allocates a unique identifier for a wheel. Wheels pass these identifiers back to sessions in their events so that sessions with several wheels can match events back to other information. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED] > -----Original Message----- > From: Rocco Caputo [mailto:troc@;netrus.net] > Sent: Monday, November 04, 2002 1:01 PM > To: '[EMAIL PROTECTED]' > Subject: Re: POE performance problem > > > On Mon, Nov 04, 2002 at 08:13:51AM -0600, Bob Maccione wrote: > > I think you should consider doing the C stuff in Inline::C, I know > > that it's a _wrapper_ over XS but the interface is pretty nice. > > Matt Cashner, myself, and a star-studded cast of thousands... well, > several people anyway, discussed Inline::C, XS, and SWIG on IRC. > Matt's the POE/XS champion and has future plans for the C code he'll > be working on. > > I don't remember why XS was decided on, though. Matt might be able to > say. > > > If you get a list of what you need migrated it might help people > > with time on their hands... > > Most of the changes since 0.23 have been a massive restructuring to > support C porting. The hottest code will be in POE::Loop::Select and > POE::Queue::Array when 0.24 is released. It's already there in the > CVS tree, but it's waiting for me to make some time to ship it. > > The Select loop wraps select(), and it includes some expensive looping > to find active file descriptors in select's bit vectors. Rewriting it > in native select() and C-level bit manipulation should make it a lot > faster, especially in programs that manage a lot of files. > > The Array queue is POE's usual event queue code. It's pretty fast for > Perl, but it's still heavily used by everything. Porting it to C, > data structures and all, should also increase POE's performance in > most areas. > > Other hot spots still exist in Kernel.pm, but I'm not sure about the > right way to migrate them to separate classes. Ultimately, POE should > support plug-in classes for new asynchronous resources (semaphores, > etc.) and new interfaces to existing ones. C plug-ins should be easy > enough to support once the architecture gels. > > Rather than rewriting POE::Loop::Select in C, it might be more > effective to develop new bridges for native kernel events libraries. > These would be POE::Loop::KQueue for BSD, POE::Loop::DevPoll for > Linux, and POE::Loop::Win32 for Windows. Not only do they run faster > and scale better than select-- even in C-- but they provide events for > more conditions, and they support OS's better. > > If people have some spare time, POE's bug tracker has all manner of > incidental and important tasks. I'll be happy to share them. :) > > -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/ >
