On Mon, Nov 12, 2001 at 09:58:10AM +0100, Miroslav Madzarevic wrote: > Hi all, > > > I never used POE so far but I think I've contributed a bit. Please read > on. > > I made some changes to the proxy.perl in samples directory of POE > distribution. It seems that you shouldn't delete wheels (serv & cli) > when you get an error but yield an event for that instead. I used port > 7010 -> 80 for forwarding and sometiemes connection dropped when I > should have got data. I fixed it by adding an eevnt and doing yield and > now it works (did a lot of testing, before it failed on every 3rd, 4th > occasion).
This may have been fixed in POE::Kernel, though. I've recently changed the way I/O events are dispatched, which should simplify I/O handlers in proxy.perl and other programs. In case I haven't fixed it, though, I still would appreciate a patch to proxy.perl. > I would like to understand better event handling. For example I used > httpd.perl in an experiment. I was sending a couple of megs on one conn. > and still it was ready to accept more connections. Seems like mltithr > but ofcourse it's all events. I don't get it now how does Filter::HTTPD > know when to invoke receive event for 1 complete http request ? I guess > the scenario is that reading takes place all of the time in small bits > and Filters get event is invoked constantly. Only when get event returns > [] with one element in it does the success event fire ? Filter::Xyz (where Xyz is Line, HTTPD, Reference, etc.) combines raw stream data in a buffer until it can recognize a complete input record. The get() method returns [] when there is nothing to return. When a complete record is found, it's returned as [$record]. Filter::Xyz return array references because a single raw read may contain more than one input record. Wheel::ReadWrite uses the return value to generate events. Filter::Xyz do not generate events themselves. > Also, I think the philosophy is to have lots of "fast" states so that > there is no blocking and if there really needs to be a long blocking sub > than you invoke Wheel::Run on it and communicate over events making > everything seem fast again. With multithreading you have kernel dividing > time as it want's. Here you have subs taking all the time they need. The > next event runs after they finish (or sooner if they use $kernel->call). > So all the subs must be very fast. States only must be fast if you want smooth multitasking. Programs can often get away with occasional slow states, and they often won't be noticed. States may also block indefinitely if you don't mind programs that only do one thing at a time. This is a perfectly valid use for POE. > What do you think what will be with POE's future when perl becomes > multithreading stable. Some people are telling me that python has > real multithreading. I wish perl was like that. [...] POE will use threads when two conditions are met. First, threads must be usefully stable. Artur Bergman is working miracles with them, and they may already be stable enough for POE. Second, I need a large block of time to add threads to POE. Artur has given me a patch for this, but documenting and testing it will still take a lot of time. For what it's worth, we've been working on threaded POE designs for a few years now. The design will be adolescent (if not mature) by the time it's actually implemented. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
