test
First test message to see if the list is up. -- Rocco Caputo / [EMAIL PROTECTED]
test 2
Second test. Hopefully the list is up *and* it isn't mirrored into [EMAIL PROTECTED] :) -- Rocco Caputo / [EMAIL PROTECTED]
test 3
test 3 ... one more try before opening it to the public -- Rocco Caputo / [EMAIL PROTECTED]
heads-up: wheel interface change
Good morning, and welcome to the new list. A session that has several wheels currently cannot tell which wheel generated an event. I discovered this while writing a Component that manages several connections: which SocketFactory should be destroyed when an error arrives? Can't tell! I've changed the wheels a little to make this possible, and one of the changes may break existing programs. These three changes won't break any code: 1. Every wheel will have a unique ID. 2. Wheels' events will include the wheel ID at the end of the current parameters. It really should be at the beginning, but that would instantly break everything. 3. Wheels have a new method: ID(). This works like POE::Session's ID: it returns the wheel's unique ID. This change probably breaks existing code: 1. Wheels must always return an object reference so that an ID method can be called on them. Otherwise it's impossible to match a constructor error back to the wheel that had the problem. This breaks code that relies on an undef return value to indicate error. I expect these changes to be in version 0.1106, and people should take care when installing it on production systems. -- Rocco Caputo / [EMAIL PROTECTED]
Version 0.1106 is on the web
Good morning! I have uploaded POE 0.1106 to the new web site. It's required for POE::Component::Client::HTTP, which also has been uploaded. That URL is <http://poe.perl.org>, by the way. Watch out! This version subtly changes wheels' constructor semantics! If you have production code that relies on wheels to return undef or false if they fail, that code will break! -- Rocco Caputo / [EMAIL PROTECTED] 0.1106 2000.09.01 - (!!!) Wheels always return object references now, even if they fail. This may break programs that rely on some wheels' (most notably SocketFactory's) new() methods returning undef when they cannot be created successfully. This change was necessary to complete the wheels-have-unique-ids change also in this version. Wheels have unique IDs now. These IDs are included in every event generated by a wheel, and they're accessible with the $wheel->ID() method. It's now possible to determine which wheel generated which event, which is useful if you have several wheels in the same session. Many of the tests determined whether a wheel succeeded by its constructor's return value. Revised them to fail if error events are thrown. - EOF: Thank you for reading. -
Version 0.1108 is on the web
Good morning!
I've uploaded POE 0.1108 to <http://poe.perl.org/>. This version
adds Gtk support and some backwards incompatibility with Tk.
I forgot to announce 0.1107, but it wasn't much to see anyway.
It's mainly a docs patch and better testing for the always
troublesome SIGCHLD handlers.
-- Rocco Caputo / [EMAIL PROTECTED]
$Id: Changes,v 1.153 2000/10/06 20:05:46 rcaputo Exp $
Revision history for POE
Changes marked with "(!!!)" may break backward compatibility.
0.1108 2000.10.06
-
Added Gtk support. Added t/21_gtk.t to test it.
(!!!) Broke Tk backward compatibility. POE supports different X
toolkits now, so it's silly to export ${"poe_${toolkit}_main_window"}
for each. Renamed $poe_tk_main_window to $poe_main_window. Both Tk
and Gtk use it for the top-level/main window.
(!!!) Broke Tk backward compatibility again. POE supports different X
toolkits now, so it's silly to have a separate DESTROY signal for
each. Renamed TKDESTROY to UIDESTROY, and both Gtk and Tk use it.
Updated POE::Kernel docs.
0.1107 2000.10.04
-
Document POE::Preprocessor's debugging constants, and allow them to be
overridden by defining them before POE::Preprocessor is used. This is
the same scheme that POE::Kernel's TRACE/ASSERT constants use.
Philip Gwyn thinks SIGCHLD was broken after 0.1104, so I've
restructured test programs 11 and 12 (POE and Event signal watchers).
Child process death is synchronized by the parent program (read:
SIGINT) instead of with sleep and Time::HiRes. They ought to die
closer together now.
- EOF -
Version 0.1109 is on the web
Good morning! POE 0.1109 is at <http://poe.perl.org/>. This one gunzips ok; I checked it first. :) Aside from some problems with SIGCHLD handling, the 0.11xx series looks pretty stable. I'm going to try wrapping this up as 0.12 Real Soon Now; if anyone notices problems, now's the time to say something. -- Rocco Caputo / [EMAIL PROTECTED] 0.1109 2000.10.30 - Revised large chunks of POE::Preprocessor. Added conditional code inclusion on the assumption that not performing macro substitution and compiling code we don't use will be faster. This could well be false. Added DEBUG_INVOKE and DEBUG_DEFINE to POE::Preprocessor, mainly so the defining and invoking output doesn't clutter up DEBUG'S. Revised POE::Kernel to use conditional code inclusion instead of optimized-away optrees. Revised t/05_macros.t to test conditional code inclusion. Revised t/01_sessions.t to time out in coverage tests. Previously, the tracing library would cause some subtle hang. Revised the coverage testing tools to cope with conditional code inclusion. Conditional code inclusion inside macros changes line numbers no matter what I do, so the coverage report has to cope. POE::Preprocessor didn't allow consts which weren't all-caps; now it does. Also permit consts which aren't all letters. This allows a crude sort of operator overloading. Lifted most of Ilya Zakharevich's nifty Text::Trie to rewrite the regexp optimizer in POE::Preprocessor. Added POE::NFA, the nondeterministic finite automaton flavor of POE::Session. Tweaked test t/00_coverage.t to load each module in a separate package. POE::NFA and POE::Session both export constants which overlap. Tweaked POE.pm to load Session by default. If NFA is specified, it overrides Session. This should prevent accidentally loading Session and NFA at once. [end]
Version 0.1110 is on the web
Good morning! I've uploaded 0.1110 to <http://poe.perl.org/>. There are some small untested patches, and the samples have been checked against the latest modules. There has been no further word on SIGCHLD, and the usual tests haven't turned up anything. I'm just about ready to let the CPAN testers find this problem. -- Rocco Caputo / [EMAIL PROTECTED] 0.1110 2000.11.11 - Added ARG1 to Wheel::ListenAccept's AcceptState parameter. This contains the accept() call's return address. Cleaned up and tested the samples. They all should work with the latest version of POE. The InterMezzo team contributed &POE::Kernel::select_pause_read() and &POE::Kernel::select_resume_read(). Added and documented them. The InterMezzo team contributed &POE::Kernel::get_active_session() and &POE::Session::get_heap(). Added and documented them. (!!!) The InterMezzo team suggested replacing exists() parameter checks with defined(). The change will make undefined parameters (in the form C undef>) look like they were not passed. This simplifies code in some cases while not complicating it anywhere. In most cases, this change should not alter the way existing code behaves. It's sweeping enough, however, than I've marked it compatibility-breaking just in case. Modules affected: FollowTail.pm; ListenAccept.pm; ReadWrite.pm; SocketFactory.pm; Block.pm; Line.pm; SysRW.pm. Note, however, than undefined InputLiteral in the Line filter has a special meaning, so its exists() check was retained. [end]
Version 0.12 is on PAUSE and the web
Good morning. POE 0.12 has been uploaded to the PAUSE and <http://poe.perl.org/>. It should appear at your favorite CPAN mirror shortly. This is the first CPAN release in about four months. Several changes have occurred in web-only releases since 0.11. Some highlights: o Added support for Gtk. Fixed Tk support. POE now can use one of four event loops: Gtk, Tk, Event, or its own perl select() loop. POE's public interface maps itself to whichever event loop is used, so the same program guts (POE::Component::IRC, for example) will work in each environment. POE supports each event loop's unique features through a generic postback mechanism. o Added a way to populate the heap at construction time or change it to something completely different. o Added POE::NFA, a true nondeterministic state machine variation of POE::Session. o Optimized the macro/const/enum source filter, POE::Preprocessor. Startup should be a little faster. o Added new tests. Extended existing ones. Revised the problematic signals tests. Skipped many tests under Windows simply because Windows does not support the features they test. Test coverage is about 70%. o Improved coverage testing. It's still far from perfect, and it always will be, but it's better than before. o Improved Wheels so their events can be tied back to which wheel generated them. This makes it possible for one session to keep track of many wheels. o Moved POE's web site and mailing list. Documented the new addresses. o Improved Filter::Line with contributed code: Added Addi's newline auto-detection code and Dennis Taylor's patch for supporting different newlines. o Improved messages in skipped tests so they don't look like problems. o Fixed Filter::HTTPD, which didn't work correctly with some clients. o Added a cheezy neural network to the samples directory. These are just highlights. The full README and Changes files are available at <http://poe.perl.org/>. Thank you. -- Rocco Caputo / [EMAIL PROTECTED]
test ignore
test ignore ... whee! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org
Version 0.1201 is on the web
Good morning. Version 0.1201 is uploaded to <http://poe.perl.org/>, and the latest Changes are included at the end of this message. POE's development tentatively has moved to SourceForge. The project's summary page is at <http://sourceforge.net/projects/poe/>. There also is <http://poe.sourceforge.net/>, which is a meta-page pointing both to poe.perl.org and SourceForge. SF's anonymous CVS seems to be broken, by the way, and I've already sent in a support request about it. Everything else I've switched on should be working. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1201 2000.12.15 - Added a program, lib/deptest.perl, which tries to determine and test the distribution's dependencies. If any are missing, it reports them, and it may stop the module from being installed. Tentatively moved POE development to SourceForge (project name: "poe", at <http://sourceforge.net/projects/poe/>). I'm really regretting it at the moment: SF is experiencing severe growing/moving pains, and all sorts of things have been broken. Documented the object layer depreciation. The object layer will be moved to a separate component after 0.13 is released. Documented the samples depreciation. They will be moved to a separate distribution after 0.13 is released. Moved POE::Kernel's data structures out of $self and into lexicals. Kept references to the structures in $self so Data::Dumper can dump the whole shebang at once. Mike Fletcher found a bug in the TRACE_SELECT code that kept it from showing the input bits for read select. D'oh. Fixed Wheel::SocketFactory to prevent it from clobbering another wheel's selects upon destruction. This fixes the longstanding "wheel swap" bug listed in the FAQ (on the web site). Replaced its blessed hashref with a blessed listref, so it should be a wee bit faster too. Fixed t/10_wheels_tcp.t to stop working around the longstanding "wheel swap" bug. This exercises the previous SocketFactory fix. Dave Paris found a recurring bug in t/04_selects.t. It was opening 40-some filehandles at once, which consistently runs out of available handles in some situations. I cut the number of handles approximately in half, so it should work better everywhere. This has the unfortunate side-effect of cutting 10 tests from the suite. We're still not sure how the environment is using extra handles, though. - EOF: Thank you for reading. -
Re: NFA design
Greets! On Sat, 30 Dec 2000 05:13:10 +0100, Torvald Riegel wrote: > >I'd like to know wether one should return the machine's reference to spawn()'s >caller or just use it to put the machine into its first state. Not returning >the reference and handling externally forced state transitions by poe_nfa_ >messages is probably cleaner. but you would need a predefined start >state/event to make this complete. POE::NFA is still very young. It doesn't even have tests. That said, I haven't established any conventions for using it. "Whatever works best for you and your program" seems to be a good rule of thumb. I try to avoid returning and using references to POE::Session and POE::NFA directly. A lot of POE's housekeeping relies on deterministic object destruction, and holding extra references to Session and NFA causes their instances not to DESTROY when Kernel expects them to. You'd need at least one (possibly more, depending on runtime modes: say active vs. passive FTP, for example) start state/event to make it work. I've always assumed that spawning a new machine would also start it up. >another thing: is there a way to directly call a state's event handler >without using invoke_state directly? although the docs say goto_state calls >the specified event's handler, the code looks like a state transitions >is being posted. State transitions (and input events) are posted through Kernel's queue to avoid race conditions. Otherwise it would be easy to post some events for the current state and then switch away from the state before they were dispatched. This makes sure events posted before a transition are dispatched before the transition is made. You could call an event handler directly, but you'd have to make sure you passed all the right parameters to it. If you need a chunk of code that's visible as an event handler and also as a plain perl function, maybe you can extract it to a common function that's called from an event handler and from someplace else. >a callable handler returning the machine's current state could be useful too. >(as machines are supposed to stop after processing their input, the owner >could check which stop state it is in or how it is progressing) That sounds useful. NFA will pass a C parameter to event handlers in 0.1204. C will contain the current state's name. NFA will also have a get_current_state() method in case something external needs to know. >what about a possibility to define handlers common to all states? one could >use that for the handler above or to handle _stop events (they'd need to >be posted, too) and postback the machine's stop state. You'd defined the handler as a named sub and then refer to it from all the states. That could get tedious, though. Actually, you wouldn't post a _stop event at an NFA instance to stop it, you'd just call its stop() method. But yeah, it would be handy if event handlers could be marked "global" and available from every state. It would be even better if the mechanism could be a little more selective, letting some states inherit certain handlers and others inherit others. I haven't used NFA much yet, so I'm at a loss for specifics. Does anyone have suggestions? >and i'd be interested in how other users think about some kind of error >handling / result posting guidelines. up to now giving commands is similar >among the components. returning values doesn't seem to. Me too! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: It *almost* makes sense...
On Wed, 3 Jan 2001 13:52:43 -0800, Rob Bloodgood wrote:
>Hi, I'm working on my first POE program (using POE 0.1203). It's purpose is
>to replace a hodgpodge of patches, scripts, and procedures between my
>database and (extremely busy) webserver.
>
>WHOA.
>
>:-)
>
>I mostly get POE, I think. I've even got some working code. But still,
>there is some weirdness that I was hoping somebody could help me clear up.
>
>The design goals of this program are relatively simple. I have two sessions
>running, one to accept connections and one to hit the database.
>
>That being the case, I started with Socketfactory.perl as my starting point,
>to get me running w/ a tcp server out of the gate.
>(is there a "more efficient", "more idiomatic" way to do this? comments?)
POE::Component::Server::TCP. Later on you said it wasn't useful because it
doesn't support binding to specific interfaces. That's easily fixed, though.
Take a look inside; it's a very tiny wrapper around SocketFactory.
I'll add an interface parameter to it for 0.1204. If you can't wait that
long, patch it and send me a diff. :)
>Then I define a session that connects to the DB, reads some info from the
>DB, and then essentially waits for a watermark to go refresh that info.
>
>The idea is,
>once the info is pre-fetched
>I can serve it out via the tcp server
>without melting my database
>(and at roughly 500,000 hits/day, all server parsed, all requiring a DB
>touch, DB melt is a VERY serious issue. *EVEN* on a Sun 450 w/ 4x400 & 2GB
>of RAM!)
I think the traditional way to do this is to put a caching proxy between
your database and the outside world. Clients hit the proxy, which tests
the watermark and melts the database as needed. All other times, the
generated HTML is served directly from the proxy's cache.
>Then, when the info I've prefetched becomes stale, I want to send an event
>to my DBFetch session to begin the refresh process. The state machine idiom
>for this is particularly convenient, actually, because I can execute in one
>state, and fetch individual rows in the "read" state, while still serving
>hits to the server session.
>
>But now I run into issues.
>
>1) At first, I couldn't keep my DB session alive...
> however, I ended up solving that by creating an alias to it so I could
>access it from another state:
># from StreamServerSession::gotline()
># print the results of DBFetch::fetch out to the socket
>$kernel->call( db => fetch => $line, $heap->{wheel} ) or die "couldn't
>execute db::fetch: $!";
>
>But that seems kinda crufty... especially the passing of the wheel as a
>parameter in another session.
call() returns whatever a state did, so you could have db's fetch state
return whatever content, and the StreamServerSession could then send it:
$heap->{wheel}->put( $kernel->call( db => fetch => $line ) );
If DBFetch's fetch state will return the query value immediately, it may
as well be a plain perl function. POE state calls have a lot of overhead
you probably can do without.
If fetch is meant to run a while and post a response back, consider using
postbacks. They're sort of callbacks that post events instead, and they
make this sort of thing a little harder to implement but overall easier
to use.
>2) When my DB session is loaded, POE stops responding to SIGINT & Ctrl-Z
>altogether. I have to kill -TERM in another window to restart my program
>and test changes... YUCK! Now, I'm using DBD::Oracle, and I've seen this
>kind of thing before, but setting trace levels SHOWS the signals arriving! I
>just don't know where they're going.
This doesn't sound right. Can you provide more information about it?
>3) The socketfactory.perl sample used a "Package as Object" session idiom,
>so I went with it... if it ain't broke, right? So, following that
>convention I copied the constructor and object methods (even tho i actually
>use the HEAP for session info). So imagine my confusion at this output:
It may not be broken, but it also probably isn't the best method for
the job. Inline event handlers still are the fastest, but use whatever
works best.
Later you said you'd fixed #3, great!
[trace omitted]
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Version 0.1203 is on the web (so was 0.1202)
I'd forgotten to announce 0.1203. I blame it on the sheer weight of testing and distributing the module. See the README for details on that. As usual, it's available off POE's main page, at <http://poe.perl.org/>, and now it's also available from at <http://sourceforge.net/projects/poe/>. The Changes since 0.1201 (which looks like my last announcement) follow. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1203 2000.12.29 - Very minor optimization to Gtk read/write resuming. Replace Gtk's noisy warning about resuming unpaused handles with quiet acceptance. Added POE::Pipe::OneWay, a portable way to create one-way pipes. It tries pipe first, then unix domain socketpair, then inet sockets before failing. Added POE::Pipe::TwoWay, a portable way to create two-way pipes. It tries unix socketpair first, two pipes, then inet sockets before failing. It can be more frugal with filehandles than two one-way pipes. Added Wheel::Run, an open2/open3 style wheel that lets sessions spawn off background processes. It takes care of the whole pipe, fork, exec deal. Removed lib/TestPipe and replaced all its uses with either Pipe::OneWay or Pipe::TwoWay. Added &many_ok to TestSetup so that lots of tests can be marked ok at once. More importantly, lots of them can be marked as skipped in one swell foop. Added t/22_wheel_run.t to test uni- and bidirectional pipes, plus the Wheel::Run wheel which uses them. 0.1202 2000.12.26 - Happy Boxing Day! Revised nearly all the documentation. Documented FollowTail's SeekBack parameter. Whoops! Changed FollowTail's object implementation from a hashref to a listref while I was in it. Added a conceptual cross-reference to POE's "SEE ALSO" section, so now it acts as a table of contents for the entire distribution. Pointed all the other SEE ALSOs at it. Replaced a stupid regexp in POE::Preprocessor with a faster one. Fixed a couple spots in SocketFactory where the conversion from hashref to listref was incomplete. Thanks to Rob Bloodgood! Added wheel IDs to the events ListenAccept emit. Changed ListenAccept's object implementation from a hashref to a listref. - EOF: Thank you for reading. -
Re: Glitch in SocketFactory::DESTROY / multiple wheels on one socket?
This was fixed some time around 0.1202. Case closed. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Tue, 20 Jul 1999 16:57:49 +0200 (CEST), Artur Bergman wrote: >On Tue, 20 Jul 1999, Rocco Caputo wrote: > >> On Mon, 19 Jul 1999 14:58:42 +0200 (CEST), Artur Bergman wrote: >> >> [sample code] >> > >> >I guess the best solution would for ReadWrite to croak if it found somone >> >else holding selects on the socket?. >> >> I think the best solution would be to allow multiple selects on >> the same filehandle, each mapping activity to a different state. >> That would support more than one wheel on the filehandle, which >> would allow for overlap while switching between wheels. >> >> This is hard to do, however, because wheels expect to do their own >> reading and writing. There would be a lot of confusion unless a >> "physical I/O" layer was interposed between wheels and the kernel. >> >> Croaking is a good work-around until a real solution can be >> implemented. > >How, and what use would there be to have several read and write selects? >If we add chained state dispatches that is solved. > >Artur
RE: It *almost* makes sense...
N]
to create a postback for the current session. In this case, the client
would give its postback to the server, and the server would call it to
send back a response.
# This code is in a client session. SESSION is this session,
# so it refers to a client.
my $my_postback = $_[SESSION]->postback( reply_with_this_event => $line );
$kernel->post( db => fetch => $line, $my_postback );
The other case is where the server creates a postback to respond to the
client. Here, it calls $_[SENDER]->postback( ... ) to create a postback
for the session that sent the query.
# This code is in the server session. SENDER is the session
# that sent this event. In this case, the sender is a client.
my $client_postback = $_[SENDER]->postback( reply_with_this_event => $line );
[code removed]
>I'm just going to venture a guess here, but is this kind of thing the
>"correct" way to do what you said you were too lazy to do correctly in
>tutorial-chat.pl?
Not really, no. The problem in a multi-user interactive chat or game
server is that sometimes responses are generated from input handlers,
and sometimes they're generated from queued events. Filehandles can
generate events continuously until they're serviced, so POE calls their
event handlers immediately to shut them up. Responses generated from
input handlers would be put right away, while responses from FIFO
events would lag behind. This can break the relationship between cause
and effect in subtly disconcerting ways.
In tutorial-chat.perl I "wimped out" and made all the responses
immediate. Later on, I wrote a chat/crossword puzzle server called
xws that goes the harder route. It posts all the responses through
POE's FIFO event queue. Either way, the responses are kept in order
of occurrence, and causality is maintained.
>Also,
>I'm curious about how the whole $wheel->put mechanism fits with the
>"flushed" state.
The "flushed" state is Wheel::ReadWrite's way of letting you know all
its output has been flushed to a file/socket handle. If a session has
sent a "goodbye" message, it should wait for acknowledgement that it
was flushed to the socket before shutting down. Otherwise the session
may _stop before the client sees the message.
You can also use it to send prompts once the output buffer has gone
empty, but be careful: the prompt will generate another "flushed"
event once it's been sent, and it's easy to go into a loop.
[Signals aren't delivered when DBD::Oracle is used.]
>> This doesn't sound right. Can you provide more information about it?
>
>Actually, I'm going to have to call this a DEFINITE Oracle issue. When I
>got a little further and was able to tell my DB session to shutdown, and I
>mean from the MOMENT the db handle was disconnected, my POE program reponded
>to Ctrl-C. This is consistent with the behavior I've seen in other Perl
>programs that use DBD::Oracle. SIGINT responds only if there is a currently
>executing statement handle, BEFORE it returns... at that point SIGINT gives
>an Oracle message:
>DBD::Oracle::st fetch failed: ORA-01013: user requested cancel of current
>operation (DBD ERROR: OCIStmtFetch) at $0 line __LINE__
>
>It may be a task of major wizardry (translated: hours of digging thru
>obscure callbacks, XS, and OCI) to find this...?
Ow! If you haven't already, try scouring the docs before grovelling
through the code. Maybe there's a clean way to disable this behavior?
>And finally:
>I would like to have a way to stop my server via a message to my daemon thru
>the socket, like:
>
>if ($line eq 'quit') {
>$kernel->alias_remove('db'); # kills the DBFetch thread
>return;
>}
>
>Now, that's a snippet of my actual code, and it causes everything to quit
>except the TCPServer. How would you suggest I signal the SocketFactory to
>shut down?
Oh, uh... I forgot to add that. Someone else recently requested a
similar way to shut down a different component of mine. To be honest,
I hadn't given consideration to programs that had to (gasp!) exit. :)
The immediate work-around is to signal the program to shut down. You
can do this by posting a simulated SIGINT to the Kernel. Since signals
propagate to their destination's children, and since the Kernel is an
ancestor of every session, signalling it will also signal everything
else. That's how OS signals are delivered, so it's okay to do it.
$kernel->signal( $kernel, 'INT' );
That will propagate a simulated SIGINT to everything, including the TCP
server.
I'm probably going to add a "stop" event to all my components so they
can be stopped upon request.
>TIA, and thanx for creating such a FRICKIN COOL module. ;-)
I'm glad y
Re: questions about some design aspects
andlers are only an issue of convenience. You can
implement them in plain Perl:
my %global_io_events =
( input_event => \&input_event_handler,
flush_event => \&flush_event_handler,
error_event => \&error_event_handler,
);
my %some_state =
( %global_io_events, # incorporate global i/o events
some_event => \&event_handler,
...,
);
my %some_other_state =
( %global_io_events, # incorporate global i/o events
some_other_event => \&other_event_handler,
...,
);
# %global_io_events aren't used directly here:
POE::NFA->spawn( inline_states => { \%some_state, \%some_other_state }
)->goto_state( ... );
Now about the immediacy of POE::NFA's state changes.
If an nfa session has a queue containing more than one event,
switching its state immediately would cause pending events to be
dispatched to the wrong states.
Consider an nfa with event-1 and event-2 destined for state-a. If
event-1 switched the machine into state-b before these events were
dispatched, then they would go to state-b instead of state-a. Here's
some code to illustrate what I'm talking about:
sub event_0_handler {
$_[KERNEL]->yield( 'event-1' ); # posted from state-a
$_[KERNEL]->yield( 'event-2' ); # posted from state-a
$_[KERNEL]->goto_state( 'state-b' ); # switch to state-b
}
Under the current code, this means "post event-1 and event-2 for the
current state, and then switch to state-b". If goto_state() were
immediate, however, event-1 would be dispatched to state-b, and
finding out where event-2 went would be even harder. Consider:
my %state_b =
( "event-1" => sub { $_[MACHINE]->goto_state( 'state-c' ) },
);
In the case of immediate state transitions, event-1 would be
dispatched to state-b which would switch the machine immediately into
state-c. Now event-2 would to state-c instead of to state-a like the
instruction order in event_0_handler implies.
Now with queued transitions, the move to state-b in event_0_handler
occurs after event-1 and event-2 have already been dispatched in
state-a. The code in event_0_handler does what it appears to.
I ran into a new problem after queuing state transitions. Namely,
synchronous I/O events began racing against against them. My code
would switch into a new state, but input would race ahead of the
transition event and continue arriving in the old state.
To fix this, I had POE::NFA re-post synchronous Wheel events through
the same queue as the state transitions. Now input after goto_state()
goes to the proper state, and race conditions are solved.
Or to say it in just a few words: Queuing state transitions and input
events simplifies event synchronization and provides deterministic
event dispatch in NFA sessions. You can look at a piece of code like
event_0_handler and know immediately what it will do.
>hmm, that's it for now. Rocco, I don't want to get on your nerves. so please
>tell me if i should stop that and rather wait for something to appear :)
No, go ahead. I may take some time to respond though.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: questions about some design aspects
I've reflowing the messages so they stay within 80 columns. On Fri, 5 Jan 2001 18:37:15 +0100, Torvald Riegel wrote: >On Fri, Jan 05, 2001 at 11:01:42AM -0500, Rocco Caputo wrote: [exceptions omitted] >> I have a detailed design document for streams, but it's not >> complete. I haven't had the inclination to do anything with them >> recently because Wheel::ReadWrite does everything I need, and lots >> of other things need more attention. > >Is it available to everyone? I'd be interested. I'll mail out copies on request, but it's several months old and I may decide to do something else when I have a chance to look at it again. Any comments on it will go into my to-do pile along with the design, and I won't answer them until I can resume work on it. >i didn'T investigate my issue (separate input notification and input >reading for wheels) any further because I though I'd better ask you >about it before. But I had a quick look at the code and thought that >it would need patching of POE::Kernel and at least a new wheel >interface. Which I assumed to be a major issue. > >And I guess the problem affects a lot of people. If you have high >amounts of incoming data, it all gets put into perl variables. As >wheel events are synchronous this might lead to other events not >dispatched as fastly and memory usage growing _rapidly_. The same if >the other end cannot put data as fast. And reading from files should >be done with wheels otherwise some fs types (nfs, ftp, ...) might >block the whole application. Input flow control belongs in Wheel::ReadWrite, and it probably can be done entirely there. I haven't given much thought to how, though. [more removed] >> >would it be possibly to implement the nfa functionality in >> >poe::session? there could be a global state in which behaviour >> >would be like with current sessions. if the sessiosn state >> >wouldn't be the global one it should act like poe::nfa. this would >> >be one more test for normal sessions and no difference for >> >nfas. it would solve the nfa start state and global handler issues >> >too. the main difference is that presently poe::nfa posts >> >synchronous calls back to make them asynchronous, isn't it? Rocco, >> >do you have any samples illustrating the problems you spoke about >> >(cause and effect misbehaviour with immediate state changes and >> >calls)? >> >> No, I'm against moving NFA code back into Session. The two classes >> have separate and distinct uses, and it would be better to properly >> enhance NFA than to blur the distinction between them. > >hmm ok, I thought it would match and NFA's could behave like >sessions. at least if there would be like I'd like them to be :) >anyway, would you be interested in an implementation approach? I don't understand. What sort of implementation? [global event handlers are a convenience] >> Now about the immediacy of POE::NFA's state changes. >> >> If an nfa session has a queue containing more than one event, >> switching its state immediately would cause pending events to be >> dispatched to the wrong states. > >I don't agree. "Real" NFAs act according to their current input, and >this includes state changes. For these state transitions aren't part >of input data at all. The programmer/designer of a machine is >responsible for doing the right thing, even if input is generated by >the machine itself. you can (roughly) describe a machine with state >z = m(z0, input_band), m being the transition function. and theorie >says that if z1 = m(z0, input.input1) is true than as well z1 = m( >m(z0, input), input1 ). And this requires immediate state >transitions, otherwise input1 can never be in context of input. Of >course work arounds are as easy as setting flags or the like, but >that'S like building a real nfa on top of poe::nfa, which probably >isn't wanted. I'm not really a computational theorist, so I'll now reiterate what you've said from my point of view to confirm whether I understand you. Correct me if I'm wrong. z1 = m( z0, input1 . input2 ) means that a given state transition function m() will move from state z0 to state z1 after it receives the combined input (input1 . input2). So then z1 = m( m(z0, input1), input2 ) should be equivalent, although m(z0, input1) may move into an intermediate state (say z2). In other words, the original statement may actually be equivalent to these two simpler ones: z2 = m(z0, input1) z1 = m(z2, input2) In the simpler case, POE::NFA may work because input2 can arrive after the state transition is enqueued. However, i
Version 0.1204 is on the web
Good morning! I've unleashed 0.1204 on an unsuspecting world. As usual, it's available from <http://poe.perl.org/> or its SourceForge project at <http://sourceforge.net/projects/poe/>. The latest changes are included herein. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1204 2001.01.13 - Fletch pointed out that SunOS has a psrinfo command to describe a Sparc's processors. Excellent! Updated the README. Added IO::Pty support to Wheel::Run. Skip the Pty tests if IO::Pty isn't available, so's not to break testing for people without it. Torvald Riegel pointed out that POE::NFA's goto_state() method required an entry event. The documentation says it's not mandatory, so I added his patch to make it optional. Added a STATE parameter to POE::NFA event handlers. STATE contains the name of the machine's current state. Added a get_current_state() method to POE::NFA. It returns the machine's current state's name. Added t/23_nfa.t to exercise bits of POE::NFA. Added code to prevent session IDs from colliding after integer increment wraps. Devolped a depreciation schedule for some iffy current features and to make the names of things more consistent. Added TRACE_RETURNS and ASSERT_RETURNS to generate warnings and/or hard errors whenever a Kernel function will return an error. Updated POE::Session's postback() documentation based on user feedback. Thanks again to Rob Bloodgood. Rob Bloodgood sent in a patch for POE::Component::Server::TCP to let it bind to specific interface addresses. The default behavior is the same as before: bind to INADDR_ANY. -End-
tentative compatibility breakage schedule
This schedule is also listed in version 0.1204's Changes file. Future .??.?? (!!!) --- POE is due for a round of breakage to make things more consistent. 1. In the wheels, rename /.*State/ to /.*Event/. Wheels don't define states, they emit events. Calling Wheels' parameters /.*State/ is inconsintent and confusing. 2. ARG0..ARG9 in built-in events are silly. The whole point of using array slices and constant offsets is to avoid positional dependencies. Using ARG0..ARG9 defeats most of this technique's benefits. D'oh! 3. Split some of the optionally useful bits out into a separate Bundle which is included in Bundle::POE. Let people install subsets of POE as needed. This may not happen, but it's listed here for others' consideration. 4. Whatever else I can break. I may as well break as much as I can in one big lump. Has anyone been holding off on requests because they'd break stuff? Now's the time to speak up. I've come up with this tentative depreciation schedule in the hopes it'll minimize people's grief. 1. Release POE as/is with this depreciation schedule. This is the RFC phase, and interested people should comment on it. This may be version 0.13. 2. Release POE with new the new parameters/behaviors/etc. and the depreciated ones side-by-side. The documentation will be altered to cover new things and briefly tell about the depreciated things. This may be version 0.14. 3. Add warnings for depreciated things. Try not to make them too obnoxious. This may be version 0.15. 4. Remove the depreciated things altogether. This may be version 0.16. My plan is to wait at least a month between each CPAN release. Bleeding edge interim releases will start off as maintenance on the previous version and then become release candidates for the next one. If it all goes as planned, this will give people at least 1/4 year to update their programs. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: cannot check poe w/ anon. cvs
It's definitely a problem on SourceForge's machine. I've tried checking out the CVS tree on each of the test machines, and it fails the same way. I've reported it a few times over the past month and a half (almost two now), and SF's admins have closed each one with "We're getting to it; please stand by." I hope they'll get around to fixing anonymous CVS after LDAP goes live. The site status page says LDAP will be here Real Soon Now, so I expect anonymous CVS to magically work Any Day Now. I'm not holding my breath, though, and I don't recommend anyone else do. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Fri, 26 Jan 2001 02:08:43 -0500, Tavin Cole wrote: >Well, /dev/tty on my machine is world-writeable.. I assume you meant to >check my machine and not cvs.poe.sourceforge.net. > >Anyway, like I said I've seen this problem before w/ anon. cvs on other >sourceforge projects. It's not a problem on my end. > >thanks :) >-t.c.
Version 0.1205 is on the web
It's at the usual locations: poe.perl.org is the main, fairly easily navigated site; http://sourceforge.net/projects/poe/ will get you to the alternative location, eventually. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1205 2001.02.12 - Added TRACE_RESULTS to lib/TestSetup. One of the tests in 0.1204 hung on a user's machine, and it was impossible to figure it out remotely without first seeing which test hung. Solaris wasn't setting termios parameters without TCSANOW. Wheel::Run wouldn't work in pty mode because the terminal parameters weren't being set. Make Wheel::Run's pty conduits run in "raw" or cbreak mode. Rob Bloodgood found some POD breakage; C<=item>s without blank lines between them, and things like that. Patch applied, and I went through everything and cleaned up some trailing whitespace (none of it significant) just for kicks. Newton Brown found a bug in POE's Tk support, which turns out to be a known issue with Tk's fileevent mechanism. Thanks to "good_call" via usenet news for pointing me at <http://www.xray.mpe.mpg.de/mailing-lists/ptk/2000-12/msg00060.html>, which explains fileevent's pitfalls and provides their work-arounds. Oh. I added a test to t/06_tk.t to exercise the fileevent bug. Added Tk workarounds to make the new failing tests pass. Hooray! Added file/line reporting in Session's trace option, so the sources of events are now reported. Apply a bunch of notes Rob Bloodgood sent in about the postback documentation in POE::Session. Added ReadWrite methods: get_input_filter and get_output_filter, so that filters' methods can be manipulated directly. - EOF: Thank you for reading. -
Re: Weirdness w/ Sockets fixed in 05?
0.1205 didn't significantly touch SocketFactory or Kernel, so I don't know what might have changed. A big flurry of fast connections and a sudden slowdown sounds like FIN_WAIT_2 getting in the way. Apache has had enough trouble with this to release a page about FIN_WAIT_2; it's been around for a long time: http://httpd.apache.org/docs/misc/fin_wait_2.html Or it may be a SO_MAXCONN problem, where the clients outpace the server until the system's connection queue fills up. If it's a bug in POE, though, I'm afraid it's just a happy coincidence that it's fixed. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Tue, 13 Feb 2001 12:58:20 -0800, Rob Bloodgood wrote: >So, I was running my server project under test load with 0.1204 (created w/ >another POE server/session pair in about 15 minutes... POE is SOOO EASY!) >and I saw a little weirdness that well, made my stomach turn: > >It would serve, say, the first hundred or so requests in a very reasonable >amount of time, then ONE connection would take 5 seconds... hanging all the >rest. Needless to say, this looked like a NASTY issue to possibly have to >chase down. > >But monday I get to work and there's a new beta available, 0.1205. >Naturally, I install and then continue working... and my slowdown went away! >(???) > >What changed? Whatever it was, it was DEFINITELY the right thing. > >Thx again. > >Rob > >
Re: Server pinging
On Thu, 01 Mar 2001 23:15:44 -0800, Peter Scott wrote:
>I'm constructing a daemon to respond to user questions about various
>services, e.g., is sendmail on such-and-such host working, is the web
>server on another host working, etc; I just came across POE and it looks
>ideal.
>
>What I'm wondering is, what class should I use for testing these
>services? I'm still trying to sort out Drivers from Wheels from Filters,
>and what I want is the ability to fire off a session that will attempt to
>connect to port 25 or 80 or whatever, then do a simple transaction in the
>appropriate protocol.
>
>Because the whole point of the program is that those actions may take a
>long time, I need to be able to get on with other stuff while I'm waiting
>for them either to complete or timeout. Again, an event-driven model looks
>right. So for writing something like this, what's the appropriate class to
>start out with for the part that has to go off to this other
>machine? Another example would be, say, pinging port 110 and checking that
>it answers a POP command. The POE documentation appears mostly geared
>towards how to listen for a connection rather than how to open one.
Here's one way to do it. Mind you, this is just a client thing. It
doesn't include the daemon bits you'll need to handle users' requests,
but most of it should be self-contained enough to work unmodified in
a server. I hope you find it useful.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
#!/usr/bin/perl -w
# This program is Copyright 2001 by Rocco Caputo. All rights reserved.
# You may use, modify and/or distribute it under the same terms as Perl
# itself.
use strict;
use lib '/home/troc/perl/poe';
use POE qw( Wheel::SocketFactory Wheel::ReadWrite Driver::SysRW Filter::Line );
###
# A generic service checker.
package Checker;
use strict;
use Carp qw(croak);
use POE::Kernel; # Imports $poe_kernel.
use POE::Session; # Imports session parameter offsets, like HEAP.
# "Spawn" a checker. This creates a POE session to connect to a
# service and check it according to a simple script. The exact script
# is determined in Checker's subclasses.
sub spawn {
my $package = shift;
# Validate parameters. Subclassed checkers should validate their
# service-dependent parameters.
my %args = @_;
foreach my $param (qw(host port)) {
croak "$package needs a '$param' parameter" unless exists $args{$param};
}
# Create a POE session to actually check the service. This is the
# equivalent of spawning a process or thread to do the work. The
# POE::Session constructor maps event names to their handlers. In
# this case, since we're subclassing Checker, we'll use package
# states. POE will invoke these in the usual Perl way,
# Chandler_start( ... )>, which means the @ISA
# inheritance chain is followed if Checker::Something doesn't
# implement &handler_start.
POE::Session->create
( package_states =>
[ $package =>
{ _start=> 'handler_start',
connect_succeeded => 'handler_connect_success',
connect_failed=> 'handler_connect_failure',
got_input => 'handler_input',
got_timeout => 'handler_timeout',
got_error => 'handler_error',
},
],
# Pass spawn's arguments to the _start event handler. See the
# notes for &handler_start next.
args => [ %args ],
);
}
# The _start handler is called immediately when a session is created.
# In this case, it's when a Checker subclass is spawned. The spawn()
# method passes its paramters to the _start handler through
#
# args => [ %args ]
#
# In the POE::Session->create() parameters. See &spawn.
#
# These arguments are used to create a postback. A postback is a
# plain code reference which, when called, posts a POE event. It does
# other magic, some of which will be covered later.
sub handler_start {
my $heap = $_[HEAP];
my %args = @_[ARG0..$#_];
# Store the parameters in this session's heap. Each session has a
# separate heap, so this Checker has different C than all the
# others.
$heap->{args} = \%args;
# Create a postback. This is used to post a response back to the
# parent session.
$heap->{postback} = $_[SENDER]->postback( status => %args );
# Start a socket factory. This will establish a connection (or
# not). The important part is that it won't block; the connection
# will occur (or not) in the background, and either a "success" or a
# "failure" event will
Re: Server pinging
On Mon, 05 Mar 2001 23:45:06 -0800, Peter Scott wrote:
[ In reference to the code in <[EMAIL PROTECTED]> ]
>May I ask a few questions about the code? I'm copying the list in case
>someone here is keeping up with it. I'm just trying to get this under my
>belt. I have been reading the documentation really thoroughly, believe
>me. In fact I had another five questions here which I've managed to delete
>through sufficient reading.
>
>The reason for putting the new SocketFactory on the heap in
>$heap->{connector} is to keep it alive, is that right? Otherwise if the
>return value were stored in something that went out of scope too soon, e.g.,
>
> my $connector = POE::Wheel::SocketFactory->new
>
>instead of
>
> $heap->{connector} = ...
>
>then the SocketFactory would be destroyed and its _stop state called when
>the current routine returned, do I have that right?
This is partially true. The SocketFactory (and the other Wheel
subclasses) works in some ways like a plain Perl object, and its
DESTROY method is called when it goes out of scope. Since a heap
persists as long as its Session instance, saving the SocketFactory
reference there ensures that it won't accidentally go out of scope.
It's also partly false. See the next session for more information
about Session destruction.
>The fail() method ends by clearing any pending timeouts. Since you've just
>deleted the reference to its session in $heap->{connector}, what would
>happen if you didn't clear them? Could a timeout be delivered to a
>nonexistent session? The _stop state of the session (if there were one)
>would get called as soon as the fail() method returns,
>right? Doesn't/shouldn't this clear any pending timeouts?
No, the Session would linger until the timeouts became due.
Generally speaking, POE::Kernel tracks six resources used by every
Session. A Session is stopped automatically when all six of its
resource counts drop to zero. Here's a complete list of resources
that affect a Session's reference counts:
Plain events
Pending timers
Child sessions
Selected filehandles
Aliases
"Extra" references
I say "generally speaking" because Sessions are sometimes destroyed
when they still have resources allocated. Consider signals and
similar things. In those cases, POE::Kernel knows the resources are
still active, and it cleans them up as best it can on behalf of the
departed Sessions.
So, no, you need to clear the timer explicitly. In fact, I hadn't
done that to start with, and the pop3 checker always failed with a
timeout.
I've done my job if your net confusion has dropped.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Server pinging
On Mon, 05 Mar 2001 19:31:31 -0800, Peter Scott wrote: > >I had been in the process of trying to grok the socketfactory.perl example >per Torvald's suggestion. Is there a need for a >POE::Component::Client::TCP on CPAN that would basically be the >InetTcpClient package from there? If a generic TCP client materializes, I'd like to include it in POE's distribution. Like POE::Component::Server::TCP, it would be widely useful. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Session::option
On Tue, 06 Mar 2001 16:18:10 -0800, Peter Scott wrote: >POE::Session doco says for _default > > See POE::Session's option() method for information about catching typos. > >The option method doco says nothing about this AFAICT. I believe, from >UTSL, that it should say that the option 'default' enables warnings for >uncaught events. You figured it out despite my best attempts at shrouding these features in undocumented mystery. I have no recourse but to relent and document them. Curses! Seriously, though, you got it right, and I've updated the docs: [...] There are three Session options: The B option turns on warnings when states are redefined. This may help catch instances when state definitions overlap. Events that are posted to states which don't exist are usually discarded quietly if there's no _default safety net to catch them. It can be quite difficult to find misspelled event names when this occurs. The B option will make this condition a fatal runtime error, quickly illuminating these errors. Note, however, that it won't help if a _default state has been defined. The B option turns on a runtime trace of dispatched events on a per-session basis. This is often better than turning on POE::KERNEL::TRACE_EVENTS since the latter will trace events for every session at once. =item postback EVENT_NAME, PARAMETER_LIST [] Thanks! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
RE: Server pinging
On Tue, 6 Mar 2001 09:38:53 -0700, Wilkinson, Mike wrote: >Actually, I've been reading this thread with interest as well. I'm >attempting to do something similar with POE. The biggest problem for me is >that I'm from an EE background, where state machines are defined more by the >transitions than what a state contains, and this appears to be more the >other way around. There seem to be two flavors of state machine: ones that produce output for each transition (http://hissa.nist.gov/dads/HTML/mealyMachine.html) and ones that do the same for each state (http://hissa.nist.gov/dads/HTML/mooreMachine.html). Have you looked at POE::NFA? It's an imperfect attempt at a classical nondeterministic state machine. At its worst, it shows that POE::Kernel can drive different kinds of state machines. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Just reading or writing?
On Fri, Mar 09, 2001 at 10:05:50PM -0800, Peter Scott wrote: > Why does POE::Wheel::ReadWrite insist on having both input and output > filehandles? I want something to fire off an event when input is received, > I don't care about output. If I read wheels2.perl correctly, it seems to > be doing that too - it looks as though it's not using the STDOUT that's > stuck in the new(). It's a long story. Here's a brief synopsis. Handle came first. When a ReadWrite wheel interacts with a single filehandle, it's specified as Handle. For read-only versions, omit a FlushedState event and don't call put(). It's still possible to put() through a ReadWrite wheel without a FlushedState event. InputHandle and OutputHandle were added later. When a ReadWrite wheel needs to work with separate input and output filehandles, they're specified separately in InputHandle and OutputHandle. The underlying read/write logic is the same. Truly separate handles might come later. It's possible to support InputHandle without OutputHandle, or vice versa, but it would add to ReadWrite's complexity. I'll be happy to include a patch if you can make it work without a runtime performance penalty. Otherwise I'll get to it when I can. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
0.1206 is on the web (and other news)
Good morning. POE 0.1206 is on the web. You can find it at <http://poe.perl.org/> or <http://sourceforge.net/projects/poe/>. <http://poe.sourceforge.net/> points to both locations in case you'd to bookmark a single URL. Computer problems and work-related travel have kept me away from POE for the past few weeks, but I'm back again. I'll be catching up on e-mail shortly. 0.1206's changes follow. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1206 2001.03.23 - Enhance POE::Preprocessor to track macros and constants per package. Now multiple files sharing the same package also share the same macros and constants. Split event substrates into other modules. It seems like the right thing to do at the moment. Karsten Sperling found that POSIX::uname wasn't supported back on 5.005_02 for Win32, but Sys::Hostname is. Applied Karsten's patch to use Sys::Hostname, which uses POSIX::uname internally wherever possible, instead. Replaced many enum/const statements with constant subs. Fewer of these mean less regexps to run against the source code, so startup should be a little peppier. Made more Kernel data structures package lexicals. Runtime should be slightly quicker. Remove Exporter use from Kernel and Session, although other modules like Carp already use it, so it gets loaded no matter what. I'm about tapped for startup-optimizing ideas that don't involve rewriting POE::Preprocessor. Removed the object layer; files are being restructured as a separate component. This is ahead of schedule. Added POE::Wheel::ReadLine. This is a Term::ReadLine subset that cooperates with POE. Now how do I test it non-interactively? Remove documentation in POE::Filter::Line and ::Block saying their put() methods can be used with single logical records. They can't. POE::Preprocessor would make regular expressions like /(|a|b)/ when a sub-expression was optional. Tweaked it to generate /(a|b)?/ instead. Rearranged the README sections in an effort to make it more readable. Fix samples/tk.perl to use C<$poe_main_window> instead of the older C<$poe_tk_main_window>. I'm surprised this was overlooked so long. Eliminated spurous CHLD signals generated by Sys::Hostname. Some tests have built-in delays. Reduce the amount of time they take to run on fast systems. Stop pausing alarm watchers unnecessarily. -End-
Re: Filter::Line (chr(0))
On Thu, Mar 15, 2001 at 03:21:26PM +0100, jotham wrote: > I'm trying to get POE to use chr(0) as my line seperator however I am not > sure how to do this. The POE::Filter::Line documentation has left me a > little in the dark. POE::Filter::Line->new( Literal => chr(0) ) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Event loops
On Thu, Mar 22, 2001 at 10:31:55AM -0800, Rob Bloodgood wrote: > I'm curious, > should I be using C in my program(s)? > > I can't find any specifics on yes or no, only that POE supports it. From > what I've gleaned about POE's operation, the most complex part of it is > state management/context switching. Since Event (task switching, async > looping) is written in C, does that imply that my program will run faster > simply by using Event? I think Event gives you two benefits over POE's own select loop: 1. Safe signals. Event polls for signals in C, bypassing Perl's problematic signal handlers and the coredumps they can cause. 2. Interoperability with other modules using Event. POE with Event generally seems a little slower. It makes some sense, since POE's record-keeping overhead is roughly constant both ways. Frobbing Event in addition to that is extra work. Here are benchmarks run on an Athlon 1GHz, using POE 0.1206 and Event 0.81. I think the differences between figures are wider on slower machines. Anyone who wants to try the benchmark program on their own systems should mail me off-list, and I'll pass along a copy. eyrie:/usr/home/troc/perl/misc$ ./bench.perl Using POE's select loop... 50 postsin33.057 seconds ( 15125.362 per second) 50 dispatches in 106.736 seconds ( 4684.451 per second) 30 alarms in26.264 seconds ( 11422.307 per second) 10 alarm_adds in51.414 seconds ( 1944.996 per second) 10 alarm_clears in 3.855 seconds ( 25941.804 per second) 10 session creates in36.550 seconds ( 2736.014 per second) 10 session destroys in96.578 seconds ( 1035.436 per second) 10 select toggles in25.488 seconds ( 3923.346 per second) 100 callsin22.905 seconds ( 43658.855 per second) 20 single_posts in32.030 seconds ( 6244.179 per second) 100 startups in32.529 seconds ( 3.074 per second) --- times --- wall : 467.992 user : 415.070 cuser:29.984 sys :14.992 csys : 2.047 eyrie:/usr/home/troc/perl/misc$ ./bench.perl event Using Event... 50 postsin33.365 seconds ( 14985.728 per second) 50 dispatches in 106.031 seconds ( 4715.597 per second) 30 alarms in26.838 seconds ( 11178.158 per second) 10 alarm_adds in52.419 seconds ( 1907.700 per second) 10 alarm_clears in 3.917 seconds ( 25530.844 per second) 10 session creates in36.620 seconds ( 2730.728 per second) 10 session destroys in96.144 seconds ( 1040.104 per second) 10 select toggles in26.035 seconds ( 3841.018 per second) 100 callsin23.077 seconds ( 43332.370 per second) 20 single_posts in32.997 seconds ( 6061.075 per second) 100 startups in33.612 seconds ( 2.975 per second) --- times --- wall : 471.835 user : 415.758 cuser:30.062 sys :15.258 csys : 2.203 -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE'd LWP
On Wed, Mar 21, 2001 at 06:13:30PM -0500, Kirill wrote: [...] > Like PoCo::Client::HTTP, it allows other sessions run while > HTTP transactions are being processed, and lets several HTTP > transactions be processed in parallel. Because it is derived > from LWP::Parallel::UserAgent, which in turn derives from > LWP::UserAgent, it gives the ability to use protocols other > than HTTP, currently FTP and HTTPS, as well as other LWP > niceties like proxying and automatic redirect and > authentication processing. It also inherits request queue > management from LWP::PUA. [...] > Would there be interest in having a POE component like that? This sounds like an excellent module, and I'm definitely interested in it. In fact, I'd like to replace Client::HTTP with it if you have the time to finish it. > The module appears to work already, so anyone is welcome to > test it. I don't know if it will compile with Perls prior to > 5.6, there are some minor differences in syntax, but they > would be very easy to fix. I tried it with https, ftp, and http protocols simultaneously, and it seems to have hanged. I'm using 5.005_03 at the moment, so maybe it works better in newer perls. Do the https and ftp protocols also run without blocking? This looks like a great start for a general-purpose user agent. Please keep me posted on its development. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: HELP! Filter::HTTPD "Didn't want any more data"
On Tue, Mar 20, 2001 at 04:56:07PM -0800, Rob Bloodgood wrote: > So I've got my project running, and naturally some tuning and bugfixing is > in order. > > All of the changes are happening in my DBFetch module. Little modifications > as to what gets incremented where, in the local heap. > > But alla sudden, my HTML reports are CRASHING the program!?! [...] > (several variations exist, *ONLY* differing in the html content). > > This code, which has worked perfectly thru development, testing, and > rollout, SUDDENLY kills the program as to TODAY with: > Didn't want any more data [...] > So, will somebody PLEASE tell me how/what/where this broke? Did I miss > something? Greets. The message "Didn't want any more data" occurs during an HTTP POST request when the request body overflows its Content-Length. It can also happen in HTTP GET if there's any sort of request body. Why would IE be overflowing its own Content-Length header? A quick "fix" would be to ignore the Content-Length, but I think that's covering some badness in Filter::HTTPD with even more badness. I'd rather get rid of the original badness than heap more layers atop it. Can you create a hex dump of your raw HTTP request, headers and all? Maybe I can glean something from that. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: PoCo::Client::HTTP
On Thu, Mar 15, 2001 at 11:39:18AM -0500, Michael J. Freeman wrote: > > Hello, > > I have a question on how to use the PoCo::C:H module. > > I am trying to connect to a site that requires that you auth, and I > have previously used the basic_authorization method to do > this. Also, I am a bit confused as to posting things to a CGI > form. Here is how I would do it without using POE: [...] Greets. I think we went over this in IRC. This is just an e-mail reply for closure. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Capturing session id's
On Wed, Mar 21, 2001 at 11:09:13AM -0800, Rob Bloodgood wrote:
> In trying to make my app as long-lived and stable as possible, I've come up
> against a snag:
> In the even that my program fails, even when wrapped in an eval loop,
> when I try to re-start things, I find that there are existing sessions in
> memory, my previous incarnations of POE::Component::Server::TCP, which give
> me bind errors( # 98 in my linux system if UR interested).
>
> It would be great if I could capture the session ID's somehow so that I
> could stop/deallocate/wait on them explicitly, before restarting.
The biggest problem here is that POE::Kernel wasn't designed to be
stopped and restarted. It may be easier to wrap the program in a
shell script that checks its return value and restarts it if there was
a problem.
> POE::Component::Server::TCP->new
> ( Port => 30003,
> Acceptor => sub {
> my ($socket, $peer_addr, $peer_port) = @_[ARG0, ARG1, ARG2];
> print "Server::TCP received a connection.\n" if DEBUG;
> # spawn the server session
> ServerSession->new($socket, $peer_addr, $peer_port);
> },
> Error=> sub { # Optional.
> my ($operation, $errnum, $errstr) = @_[ARG0, ARG1, ARG2];
> print "Server::TCP detected $operation error $errnum: $errstr\n"
> if $errnum;
> $::try++, die "\n" if $errnum == 98;
> },
> );
Maybe you don't need to die there. Here's an off-the-cuff
"meta-server" that respawns a server whenever it receives a
'new_server' event. The server, created within the 'new_server' event
handler, posts the meta-server a 'new_server' event whenever it dies
with error 98.
The one undocumented bit is that the TCP server component holds its
socketfactory wheel in $_[HEAP]->{listener}. You'll need to delete
that for the component to shut its listening socket down. Client::TCP
in POE 0.1207 or later will include a 'shutdown' event handler that
deletes $_[HEAP]->{listener} for you.
POE::Session->create
( inline_states =>
{ _start => sub {
$_[KERNEL]->alias_set( 'meta_server' );
$_[KERNEL]->yield( 'new_server' );
},
new_server => sub {
POE::Component::Server::TCP->new
( ...,
Error => sub {
my ($operation, $errnum, $errstr) = @_[ARG0, ARG1, ARG2];
# Shut down the TCP server component.
if ($POE::VERSION < 0.1207) {
delete $_[HEAP]->{listener}; # undocumented
}
else {
$_[KERNEL]->yield( 'shutdown' ); # documented after 0.1206
}
# Start a new TCP server component. This probably
# should go last, since it allows the 'shutdown' event
# to be dispatched before 'new_server' starts a new
# server.
$_[KERNEL]->post( meta_server => 'new_server' )
if $errnum == 98;
},
);
},
}
);
I've also added an Alias parameter for Server::TCP so they can be shut
down from outside themselves. This will appear in 0.1207 or later.
>From the new documentation:
=item Alias
Alias is an optional name by which this server may be referenced.
It's used to pass events to a TCP server from other sessions.
Alias => 'chargen'
Later on, the 'chargen' service can be shut down with:
$kernel->post( chargen => 'shutdown' );
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Wheel::ReadWrite input handling
On Thu, Mar 22, 2001 at 01:44:01AM +0100, Torvald Riegel wrote: > i'd like to change ReadWrite's input handling. currently you have to > call select_pause_read yourself with an extra file handle copy or > get it directly from the wheel, to stop the wheel from flooding. > pause/read-input methods should be enough for this, although the > session has to control it and manage buffers if needed. [...] > does this look fine for everyone? if so i will write the code (unless someone > else would do it). I would appreciate it if you could extend Wheel::ReadWrite to perform input flow control. Others have encountered event floods when reading with Wheel::ReadWrite, so it's a common problem in search of a solution. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
version 0.13 is on the web, sourceforge, and PAUSE
Good morning! After far too long, POE 0.13 is released. A lot of pending work isn't in this release. The list of changes since 0.12 (the last CPAN release) is scarily long, and I decided to just cut it off here while things pass their tests. This is a major release, and it will be available on your favorite CPAN mirror after the usual propagation delays. The impatient can get it right now from Sourceforge or poe's home page: http://poe.perl.org/ http://sourceforge.net/projects/poe Here's a summary of the changes since 0.12: Bug fixes! More than you can shake a stick at! Optimizations! We got some of them, too! Documentation! It's been overhauled yet again! Reorganized event loop interfaces, making them plug-ins. POE::NFA is developed more, although recent contributions to it aren't included yet. New TRACE and ASSERT flags for developers. New Wheel::Run to fork child processes and interact with them asynchronously. New Wheel::ReadLine to accept input from users, with many editing keybindings and an input history. New Wheel::Curses to accept input from Curses.pm; manipulating the screen is left as an exercise for the programmer (for now). POE::Component::Server::TCP instances can be shut down. Filter::Stackable to chain filters into complex configurations. This approximates a protocol stack. Detailed changes are included. I plan to accelerate CPAN releases so that the accumulated changes between them aren't so damned long. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.13 2001.04.20 --- Add Dieter Pearcey's Stackable filter, allowing ReadWrite (and other wheels) to pass data through two or more filters. Stackable comes with other helpful filters: Map and Grep to transform data while it's still in a filter stack, and RecordBlock to group several records into a block of them. Add t/24_filter_stack.t as a start for testing stackable filters. This so far is the only sample code for using these filters, and it's not very friendly in that regard. Add ASSERT_USAGE. Setting this POE::Kernel debugging constant causes it to check the values passed to its parameters and croak if they're bad. (!!!) David Huggins-Daines discovered that POE versions 0.1205 and later don't work with older Tk versions. Make the Tk substrate fail if it's working with an older Perl-Tk library. (!!!) Gtk+ does not require a top-level window in order for POE to use its event loop. Furthermore, Mandrake says it's common for Gtk+ programs not to have any given "main" window which closes a program when it's destroyed. POE::Kernel no longer creates a top-level window when using Gtk+, and it has a new method, signal_ui_destroy, which can be used to fire UIDESTROY when some arbitrary widget is destroyed. See the POE::Kernel documentation. Tk requires at least one widget to use the event loop, so POE::Kernel continues to create one and set $poe_main_window when Tk is in effect. (!!!) Depreciate support for coderefs in SocketFactory's SuccessState and FailureState parameters. Applied Peter Scott's code/doc/test patches to allow Wheel::Run to fork off coderefs instead of new programs. David Huggins-Daines pointed out that Sys::Hostname, while it's improved in 5.6.0, is pretty poor in prior perls. Added a manual POSIX::uname check in POE::Kernel. Peter Scott pointed out that Wheel::Run won't flush output to a child process' STDIN unless a StdinEvent parameter is included. Changed Wheel::Run to flush to the child's STDIN handle even without StdinEvent. Added an Alias parameter to POE::Component::Server::TCP so that it can receive events from other sessions. Added a 'shutdown' event handler to POE::Component::Server::TCP. Combined with the component's alias, this lets some other session shut down a server. Began using SourceForge's compile farm for cross-platform testing. The time reduction in POE's signal tests was too aggressive, causing some problems on the Debian test system. Increased the delay a little bit. Add POE::Wheel::Curses to provide non-blocking input for Curses programs. 0.1206 2001.03.23 - Enhance POE::Preprocessor to track macros and constants per package. Now multiple files sharing the same package also share the same macros and constants. Split event substrates into other modules. It seems like the right thing to do at the moment. Karsten Sperling found that POSIX::uname wasn't supported back on 5.005_02 for Win32, but Sys::Hostname is. Applied Karsten's patch to use Sys::Hostname, which uses POSIX::uname internally wherever possible, instead. Replaced many enum/const statements with constant subs. Fewer of these mean less regexps to run against the source code, so startup should be a little peppier. Made more Kernel data structures package lexical
Re: 0.14 test patch
On Sat, May 05, 2001 at 04:33:04PM -0700, Peter Scott wrote: > t/22_wheel_run.t failed tests 16-21 on one of my systems, much to my chagrin, since >it was testing code I submitted. The problem is in the test; it hardwires >/usr/bin/perl whereas perl is not in that location on this system. Forthwith, a >patch: [patch] Applied; it'll be in 0.15. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: help with debug
If I understand the problem, it's not so much finding out why
$kr_states is being freed after it's already free. The real problem
is finding out why the program has suddenly exited without any other
sort of error message?
That will be rough to find in a long-running program. I wish it could
be made to fail sooner. Does anything in the log up to the final
message indicate a failure in progress or about to occur? Could you
increase the amount of logged information, possibly including
watchpoints to help narrow down the problem's location?
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
On Tue, May 08, 2001 at 11:45:21AM +0200, Gabriel Kihlman wrote:
>
> Hello list,
>
> I have noticed sometimes that longrunning processes suddenly dies and
> all the log contains is
>
> [ ..application log snip.. ]
> Attempt to free unreferenced scalar at
> /usr/lib/perl5/site_perl/5.00557/POE/Kernel.pm line 1428.
>
> [ restart ]
>
> This is perl 5.005_57 and POE 0.11.
>
> I realize POE is at 0.14 and there exists newer perlversion but it is
> quite a hazzle upgrading these machines.
>
> The line the log refers are in run():
>
> # Dispatch one or more FIFOs, if they are available. There is a
> # lot of latency between executions of this code block, so we'll
> # dispatch more than one event if we can.
>
> my $stop_time = time() + FIFO_DISPATCH_TIME;
> while (@$kr_states) { <-- here..
>
> TRACE_QUEUE and do {
> my $event = $kr_states->[0];
> warn( sprintf('now(%.2f) ', $now - $^T) .
> sprintf('sched_time(%.2f) ', $event->[ST_TIME] - $^T)
> .
> "seq($event->[ST_SEQ]) " .
> "name($event->[ST_NAME])\n"
> )
> };
>
> I am suspecting that something else is going wrong withe my
> application and during shutdown things get garbagecollected and POE
> gets caught with its pants down.. :-)
>
> Any suggestions on how to trace this?
>
> --
> Gabriel Kihlman (gk)
>
>
>
Re: POE HTTP.pm module and cookies?
Good morning, Brian. I think I have this fixed in the next version, which isn't released yet because of an outstanding bug. I'd like to be sure, though. Could you mail me a patch off-list? Thank you. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Tue, May 15, 2001 at 11:50:23AM +0100, Brian Agnew wrote: > Hello, > > I encountered a problem last night whilst using the > POE::Component::Client::HTTP.pm module to query a web site that returned > cookies. > > My code fell over at line 252 of HTTP::Cookies.pm, since the HTTP::Response > object didn't have a reference to the corresponding HTTP::Request object. If I > inserted the corresponding reference in POE::Component::Client::HTTP.pm prior > to the extract_cookies method (line 335), then it worked ok. > > Has anyone else encountered this problem ? I'm pretty sure I'm up-to-date wrt. > all my libraries. I can submit a patch if need be. > > Brian > > = > Brian Agnew http://www.oopsconsultancy.com > OOPS Consultancy Ltd > +44 (0)20 8767 8028 > > > Do You Yahoo!? > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > or your free @yahoo.ie address at http://mail.yahoo.ie >
Re: Client::HTTP and GETs ?
Thanks! This will be fixed in the next release. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Wed, May 23, 2001 at 05:33:19PM +0100, Brian Agnew wrote: > Hi, > > I noticed a problem with issuing GET requests with parameters using > POE::Component::Client::HTTP. eg. if I construct a request using HTTP::Request > like so: > > my $req = GET "http://localhost/query?a=b"; > > then POE issues the GET request thus: > > GET /query > > ie. the parameters are missing. I think the issue is that the HTTP.pm module is > calling URI::URL method path() instead of full_path() (v 0.35, line 262). > Calling path() on $req above yields /query. Calling full_path() yields > /query?a=b, which I think is correct. POSTing works ok. > > Thoughts ? I'm pretty sure I'm up-to-date wrt. versions etc. > > Brian > > = > Brian Agnew http://www.oopsconsultancy.com > OOPS Consultancy Ltd > +44 (0)20 8767 8028
Re: select() as sleep()
I've patched POE::Kernel to import Time::HiRes' sleep() along with time(), if the module is available. This sleep() will convert floats into usecs and call usleep internally. I've patched POE::Kernel::Select to use sleep() (which may be Time::HiRes' if available) when there are no filehandles and $^O eq 'MSWin32'. Otherwise it still uses four-argh select(). This'll be in the next release. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Thu, May 24, 2001 at 12:34:54PM -0400, Kirill wrote: > When there are pending alarms but no handles, select() is called > to sleep with subsecond precision, as advertised in select(2). > > However, on Win32 it does not seem to work like that. Instead, > select() returns immediately (with a failure, I believe). > > When there are no handles and the timeout is > 0, could we try > calling Time::HiRes::usleep instead? Don't know if that's more > portable, but I think I heard somewhere that Time::HiRes is > going to become a core module soon. > > Otherwise, when there are no handles and the timeout is >= 1, > could we call sleep(int($timeout)) before calling select()? > > Kirill > >
Re: select() as sleep()
If I read the messages correctly, you need to keep refreshing a timer whenever activity occurs. POE::Kernel's alarm() and delay() methods do this: they clear existing timed events for the given state before setting new ones. So every time you call this: $kernel->delay( timeout => 5 ); The previous 'timeout' delay is cleared and a new one is set for five seconds into the future. To clear the delay it without setting a new one, you would call this: $kernel->delay( 'timeout' ); Since delay() clears the previous one (if any), it removes the old 'timeout' delay. Since there is no time for a new 'timeout', no new one is set. This may not help if I misunderstood your previous message. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Thu, May 24, 2001 at 06:24:51PM -0400, Kirill wrote: > Great! Are we going to have an official way to do timeouts in > the next release? Or did I miss something that's already there? > > Kirill > > > > I've patched POE::Kernel to import Time::HiRes' sleep() along with > > time(), if the module is available. This sleep() will convert floats > > into usecs and call usleep internally. > > > > I've patched POE::Kernel::Select to use sleep() (which may be > > Time::HiRes' if available) when there are no filehandles and $^O eq > > 'MSWin32'. Otherwise it still uses four-argh select(). > > > > This'll be in the next release. > >
version 0.1401 is on the web
As usual, you can find it at <http://sourceforge.net/projects/poe/> or <http://poe.perl.org/>. Many suggestions aren't in this version. It was released anyway because the CHANGES list was long enough. This is a maintenance release (0.1401 instead of 0.15) because of the recent work-around for bogus select() without filehandles on Win32. I don't have a test machine, and I didn't want to inflict an untested change on the CPAN. Note: The missing date in CHANGES is not yet set. It will be about 28 days after the next CPAN release. See the new TODO file for more on this. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1401 2001.05.28 (!!!) --- (!!!) Tk postbacks must return 0. Gtk postbacks must return 1. Actually, Gtk postbacks might return 0, too. The test relies on 0, anyway, but mandrake says he needs postbacks to return 1. I'm so confused! Leave Gtk's postback return value 0 for now, but it might change later. (!!!) Depreciation schedules and other notices have been moved to a TODO file. Please consult that file or be surprised later. (!!!) Changes has been renamed to CHANGES to follow suit with MANIFEST and README. (!!!) Breakage warning! XyzState parameters in wheels have been renamed to XyzEvent and documented as such. They are guaranteed to work without warnings until .??.??. Fix t/06_tk.t to skip if Tk is outdated, rather than fail. Fix lib/deptest.perl to recognize Exporter on Solaris. Increase dependency checking information on Solaris in case attempts to fix the Exporter bug aren't successful. Add XyzEvent support to wheels. Code to support XyzEvent and XyzState is marked with the comment C<# STATE-EVENT>. Hooks for depreciation warnings are also commented. Changed the documentation to say XyvEvent instead of XyzState, so new users will not learn the depreciated ways. Verified that the depreciation from State to Event does not break existing tests. Ported the existing tests to use XyzEvent instead of XyzState, and verified that they still pass. Added instructions for installing the ActiveState PPM to README. Ported the samples from XyzState to XyzEvent, but they still are not properly tested. Add POE::Kernel methods detach_myself() and detach_child() to detach the current session from its parent, or a child session from the current one. This breaks the existing parent/child relationship, allowing parent sessions to be garbage collected if they're no longer needed. It resembles the fork/exec trick in Unix. Added test t/25_detach.t to test detaching sessions. Fixed a typo in POE::Kernel; the bareword "hostname" should be $hostname, what with all the work Kernel does to set it properly. Ray Brinzer's (SF: petruchio) keen eye spotted this one. Win32's four-argument select() call fails when there are no filehandles. In this case, call sleep() instead. Have Time::HiRes import its own sleep() if it's available, so that subsecond sleeps will work. -End-
Re: select() as sleep()
On Fri, May 25, 2001 at 12:18:53PM -0400, Kirill wrote: > Sorry I wasn't too clear in my initial message. [...] I think the blame's mine for rushing through your message. An interface for removable alarms was documented on the list about two years ago, but I never got around to implementing it. I've excerpted that message here and in the TODO file so people can comment on it before I start coding. I'll be adding other suggestions from this list to the TODO file in the next few days so I can move those messages out of my inbox. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net --- Improve Alarm Interface --- > From [EMAIL PROTECTED] Thu Mar 18 09:20:36 1999 > Message-Id: <[EMAIL PROTECTED]> > From: "Rocco Caputo" <[EMAIL PROTECTED]> > To: "The POE Mailing List" <[EMAIL PROTECTED]> > Date: Thu, 18 Mar 99 09:17:02 -0500 > Subject: TODO: fix alarms > > [...] If there are no objections, this will go into 0.07_01 or so, > depending on my schedule. [...] > > | ***fix alarm semantics (in a way that does not break things) > | > | That's easy to say, anyway. How about depreciating &Kernel::alarm > | and &Kernel::delay, and adding these functions? > | > | $alarm_id = $kernel->alarm_set($time, $event, @etc); > | $kernel->alarm_adjust($alarm_id, $seconds_to_adjust); > | $kernel->alarm_remove($alarm_id); > | > | Also the delay shortcut, which would return an ID usable by > | &Kernel::alarm_adjust and &Kernel::alarm_remove: > | > | $alarm_id = $kernel->delay_set($seconds, $event, @etc); Needless to say, this didn't make it into 0.07_01 (see the CHANGES file for what did). Anyway, the interface seems to have survived the test of time: I still like it, and so do others who have seen it. Internally, I'd maintain yet another hash: %kr_alarm_id_to_time, which would be keyed on alarm ID and contain the corresponding alarm time for that ID. The alarm_xyz() methods would manage the time: adjust would adjust it, etc., so it always matches the time in the queue. The implementation can reuse the linear/binary seek code from _enqueue_alarm to find alarms by time (id->time lookup above) and remove/add/adjust alarms relatively quickly. Ideally, though, it's possible to schedule delayed alarm queue sweeps. I'd like to try that after some more planning. See "Delay Garbage Collection" elsewhere in this file. The old alarm interface would be depreciated. Perhaps it would be reimplemented as a layer atop the new interface, for compatibility, and then be depreciated. -End-
poe components available on the web and CPAN
Greets. I've uploaded new versions of these components to PAUSE and <http://poe.perl.org/>. Your favorite CPAN mirror will have them shortly, although the CPAN shell may not be able to find them until they're categorized in the modules list. 0.92 POE::Component::Client::DNS 0.36 POE::Component::Client::HTTP 0.92 POE::Component::Client::Ping 0.51 POE::Component::JobQueue Their README and CHANGES files are also at poe.perl.org. Enjoy! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
revised alarms todo (getting coded this time, honest)
Good morning! I started writing the new alarm functions from the TODO document, and then I realized nobody has had a chance to look at the changes after Kirill's suggestions. Here's a copy of the newest alarms notes. I'm only implementing alarm_set(), alarm_adjust(), and alarm_remove() until people have had a chance to comment on the rest. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net --- Improve Alarm Interface --- Swapped event/time in alarm_set() and event/seconds in delay_set() based on feedback from Kirill. Added alarm_remove_all() to clear all alarms, based on feedback from Kirill. I'm not sure how useful this one will be. > From [EMAIL PROTECTED] Thu Mar 18 09:20:36 1999 > Message-Id: <[EMAIL PROTECTED]> > From: "Rocco Caputo" <[EMAIL PROTECTED]> > To: "The POE Mailing List" <[EMAIL PROTECTED]> > Date: Thu, 18 Mar 99 09:17:02 -0500 > Subject: TODO: fix alarms > > [...] If there are no objections, this will go into 0.07_01 or so, > depending on my schedule. [...] > > | ***fix alarm semantics (in a way that does not break things) > | > | That's easy to say, anyway. How about depreciating &Kernel::alarm > | and &Kernel::delay, and adding these functions? $alarm_id = $kernel->alarm_set($event, $time, @etc); $status = $kernel->alarm_adjust($alarm_id, $seconds_to_adjust); $status = $kernel->alarm_remove($alarm_id); > | Also the delay shortcut, which would return an ID usable by > | &Kernel::alarm_adjust and &Kernel::alarm_remove: > | > | $alarm_id = $kernel->delay_set($event, $seconds, @etc); To remove all alarms for a given event or time. I'm not sure how useful these are yet. $status = $kernel->alarm_remove_by_event($event); $status = $kernel->alarm_remove_by_time($time); To remove all alarms for the current session: $status = $kernel->alarm_remove_all(); Should alarm_remove() be alarm_remove_by_id() ? Needless to say, this didn't make it into 0.07_01 (see the CHANGES file for what did). Anyway, the interface seems to have survived the test of time: I still like it, and so do others who have seen it. Internally, I'd maintain yet another hash: %kr_alarm_id_to_time, which would be keyed on alarm ID and contain the corresponding alarm time for that ID. The alarm_xyz() methods would manage the time: adjust would adjust it, etc., so it always matches the time in the queue. The implementation can reuse the linear/binary seek code from _enqueue_alarm to find alarms by time (id->time lookup above) and remove/add/adjust alarms relatively quickly. Ideally, though, it's possible to schedule delayed alarm queue sweeps. I'd like to try that after some more planning. See "Delay Garbage Collection" elsewhere in this file. The old alarm interface might be depreciated. Perhaps it could be reimplemented as a layer atop the new interface, for compatibility, and then be depreciated.
batch removal functions
Ok! Added to TODO: -- Batch Remove Resources -- Abigail wanted a clean way to stop all alarms in a session that was getting ready to go away. alarm_remove_all() would do this. Peter J. Braam wanted a way to flush all pending events for a session. This would be FIFO events, since there would already be a method for alarms. Kirill would like a way to batch-remove all selects when it's time for a session to shut down. -End- There are no guarantees as to when these will be implemented, though. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Fri, Jun 01, 2001 at 10:09:14AM -0400, Kirill wrote: > Some form of batch remove would certainly be useful. If the user > wants to drop all pending requests, that's when the current > one argument alarm comes in very handy. alarm_remove_by_event > will probably be optimal in most cases. > > Incidentally, in that same situation I am also removing all > select()ed sockets, and obviously right now it has to be done > one by one. So I thought a similar interface for removing > sockets would also help, although it's really not that important. > > Kirill
version 0.1402 is on the web
"The web" meaning <http://sf.net/projects/poe/> and that poe.perl.org site. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1402 2001.06.03 - Have the child process in Wheel::Run attempt to kill itself if POSIX::_exit() isn't available. Document a lot of requests and things in TODO. Add alarm_set, alarm_adjust, alarm_remove, and alarm_remove_all to POE::Kernel. Add tests for these things in t/02_alarms.t. Document them in POE::Kernel's manpage. Depreciate POE::Kernel's queue_peek_alarms() method. The new alarm functions let programmers add, remove, and track alarms by ID, so looking into the alarm queue is no longer necessary. The complete depreciation schedule is in TODO. Add POE::Kernel leak detection for alarm IDs. Discovered a memory leak in alarm IDs, and removed it. Add POE::Kernel leak detection for signals, completing the suite of global structure leak detectors. Discovered and fixed a potential memory leak in signals data structures. -End-
version 0.1403 is on the web
http://poe.dynodns.net/ http://sf.net/projects/poe/ Version 0.1403 is mainly a bugfix for people running older perl versions. I'd slipped some zero-width negative look-behind assertions into regexps here and there, and someone's 5.004_05 production system couldn't cope. This is another release candidate for the CPAN release of 0.15. Please let me know POE still has breakage, especially when run with perl versions after 4.036 and before 5.6.0. Thanks! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1403 2001.06.07 - Added POE::Kernel method alias_list() to return the alias(es) associated with a particular session. Documented alias_list(), and added tests to t/03_aliases.t Changed case of Changes in NEEDS. Added TODO to NEEDS. Applied Philip Gwyn's patches to remove zero-width negative look-behind assertions from lib/deptest.perl. They were preventing the dependency checker from running under 5.004_05. Applied Philip Gwyn's patch to prevent t/18_filter_line.t from dying outright when compiled regexps aren't available. D'oh! POE::Wheel::ReadLine also used a zero-width negative look-behind assertion for an elegant single regexp that transposes words. The code that replaces it is 36 lines long, but it works with 5.004_05. -End-
Re: alarm_adjust problem
On Mon, Jun 04, 2001 at 07:11:27PM -0400, Kirill wrote:
> alarm_adjust causes the alarm queue to go out of order (time-wise),
> so alarms don't get delivered on time, and the alarm search fails
> sooner or later.
I'd like to fix this right away. Can you provide a small test case?
> The workaround is to use alarm_remove and alarm_set instead.
>
> Is it normal for alarm time to become negative? When it says
>
> *** Alarm times: ...
This message's alarm times are offset from time(), and it's normal to
see negative values. This means the event loop is lagging behind
alarm dispatch, possibly because a previous event handler took too
long, because the time between alarms is faster than the loop can
dispatch, or because an alarm was set or adjusted into the past.
The select() timeout code is designed to handle negative values; if
there is a problem, I'll need to verify that and fix it right away.
> sometimes one or more of the alarms in the queue show negative
> time. Then POE dispatches a few select_* events, and only after
> that it dispatches the alarm event. Is this normal?
Yes, this is normal. Timed events are implemented in terms of
select() so that code like this won't prevent file activity from
generating events:
sub alarm_event_handler {
$_[KERNEL]->delay( alarm_event => -1 );
}
If the select() loop didn't poll filehandles in this case, then the
main loop would busy itself with alarm dispatches to the exclusion of
file events.
See &substrate_main_loop in POE/Kernel/Select.pm for the code that
coordinates select(), alarms, and posted events.
> By the way, the http://poe.sourceforge.net/packages/POE.ppd
> file currently points to POE version 0.13.
The PPD is maintained by the volunteer efforts of Douglas Couch, and
it tends to lag slightly behind the .tar.gz distribution.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: yield, alarm and signal precedence
On Mon, Jun 04, 2001 at 05:10:06PM -0700, Wilkinson, Mike wrote: > > I appear to have confused myself. The order for POE's built-in select > appears to be: > > I/O callbacks (from wheels and such) > alarms (zero or negative times remaining) > queued states (via yield) > > Signals appear to be all over the place, depending on which one it is. > > Still not sure how Event.pm effects this however, I need to install it > first. > > - MW The priority of I/O callbacks and alarms may vary depending on the event loop, but queued events are handled by the loop's "idle" callback. That gives them the lowest priority across the board. I can't guarantee this for future event loops, though I'll try to ensure it. If some event loop doesn't have an idle callback (or a local equivalent), then the priority might change. Regardless of the event substrate (Select, Event, Gtk, Tk, or some new one), I work to keep event dispatch order deterministic: Signals are enqueued at the time the signal is caught. They're dispatched whenever they reach the start of the FIFO event queue. I did this to minimize the work done in signal handlers. Enqueuing an event is several times cheaper than dispatching a signal. I/O callbacks are dispatched willy-nilly because they can occur in any order. They aren't queued because select() would keep signalling that a file was ready 'til the event was dispatched. That could be several iterations of the main loop in $poe_kernel->run(), and each iteration would see a duplicate "hey, it's ready!" enqueued. Alarms are dispatched in time order. Where two or more alarms are set for the same time, they are dispatched in the order in which they were set. They have priority over FIFO events on the assumption that they've been waiting a while to be dispatched. time() is frozen (into $now) for the duration of a dispatch iteration, so the alarm queue will eventually catch up. Queued states are dispatched in FIFO order, after everything else is done. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE::Component::Client::UserAgent 0.03 available
On Thu, Jun 07, 2001 at 03:29:46PM -0400, Kirill wrote: > The third version of POE::Component::Client::UserAgent is at > http://www.en-directo.net/poe/ > > Distribution: > http://www.en-directo.net/poe/POE-Component-Client-UserAgent-0.03.tar.gz > > Manpage: > http://www.en-directo.net/poe/useragent.html > > Changes: [...] Most excellent! Does it understand proxy environment variables? Someone using POE::Component::Client::HTTP needs to hop their firewall, so I can point them at your module if it does that. > I've applied for a CPAN developer ID, but no response yet. > How does one add a component to the POE::Component namespace? You upload the module to your CPAN directory and follow the docs/form for requesting an entry in the modules list. The POE::Component namespace is sort of a free-for-all so people can contribute without me having to coordinate everything. Ahm... I think I documented why POE::Component exists in its manpage. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE at YAPC and stem
On Thu, Jun 07, 2001 at 08:12:19PM -0400, [EMAIL PROTECTED] wrote: > How many POEers are going to be at YAPC next week? I'd be great to spraf. > What's more, Uri wants to meet and chat about stem and POE integration. Not me. :( > Stem, for those that don't know, is roughly equiv to POE with IKC and a > bit of auto-config coolness thrown in. I'm definately studying stem to be > able to pull the cool stuff into my POE + IKC world. > > As to integration, I see several possibilities (in order of drasticness) : > > - write a stem-compatible protocol/serializer module for IKC That should be pretty easy, especially if stem is using a standard data serializer from the CPAN. POE::Filter::Stem? > - Get the event loops to cooperate, so that the messages can be routed > w/in the same process If I recall correctly, stem uses Event for its event loop. It should be possible for both loops to work together if you use Event with POE too. Getting events across the POE/stem paradigm barrier will require a big chunk of thought, but it should be doable, at least from Session space. Postbacks might help, but I don't know for sure. > - Throw out the POE event loop and move all our code to stem. What you say?! :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE at YAPC and stem
On Fri, Jun 08, 2001 at 12:56:42AM -0400, [EMAIL PROTECTED] wrote: > > On 08-Jun-2001 Rocco Caputo wrote: > > On Thu, Jun 07, 2001 at 08:12:19PM -0400, [EMAIL PROTECTED] wrote: > >> - Throw out the POE event loop and move all our code to stem. > > > > What you say?! :) > > ALL YOUR EVENT LOOPS ARE BELONG TO US! Oh, right! There's one more option: POE::Kernel::Stem. You still would need to upgrade Perl since that's just Event several times removed. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: alarm_adjust problem
On Fri, Jun 08, 2001 at 12:37:36PM -0400, Kirill wrote: > > > alarm_adjust causes the alarm queue to go out of order (time-wise), > > > so alarms don't get delivered on time, and the alarm search fails > > > sooner or later. > > > > I'd like to fix this right away. Can you provide a small test case? > > Here's how to reproduce the bug: [...] Tested, verified, and this will be fixed in the next version. Thanks! The next version won't be released for a few days, but there are other ways to get the fix in an emergency: Anonymous CVS from <http://sf.net/projects/poe/> is probably the best way. Bonus: I tag each release as v#. (or v#.## for the CPAN releases), so you can update/checkout by version number. Or e-mail me off-list, and I'll send a patch relative to 0.1403. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Events not being triggered
exit 0;
> }
> },
> ...
So anyway, why didn't your code work?
The parser session has nothing to do: no events to handle, no alarms
to wait for, no filehandles to watch, etc. Part of POE::Kernel's job
is to keep track of what sessions need to do. As sessions become
idle, the Kernel recognizes that and stops/deallocates them.
Back to the parser: it has nothing to do, so it's stopped right away.
By the time the player has entered her first command into the input
session, your parser is already dead. You can see it happen by adding
a _stop state to the parser:
_stop => sub { print "Stopped you say?!\n" },
Input tries to call "parse_line" on a session that no longer exists.
By design-- mainly to facilitate pluggable systems-- these events are
quietly dropped. If you'd rather them not be discarded without a peep
(perhaps while developing), you can turn on some debugging behavior
within POE::Kernel. Before using POE, define this constant function:
sub POE::Kernel::ASSERT_SESSIONS () { 1 }
use POE;
...
See the POE::Kernel manpage for the other ASSERT_XYZ things you can
do (ASSERT_DEFAULT turns them all on at once).
Anyway, aliases are a weak form of inter-session communication.
They're like named sockets or something. They promise to POE::Kernel
that their sessions will receive events from the great beyond: from
some other session besides itself. The Kernel recognizes this and
keeps aliased sessions alive until every other session becomes
dormant.
When that happens, POE::Kernel recognizes that the enitre program has
gone idle, and it kills off everything left over (including aliased
sessions). This way zombie POE programs don't eat your machine's
brains. A quick rundown of the events which lead to your program's
demise:
1. The player presses C-c, generating an "interrupt" in the input
session.
2. The input session deletes its wheel.
3. POE::Kernel sees that every session is alive by virtue of their
aliases alone. Nothing further will happen in this program, so it
kills off the remaining sessions.
4. The sessions stop and are garbage collected.
5. POE::Kernel sees that there are no more sessions, so
$poe_kernel->run() finally returns, and the main program exits.
By the way, I have some perl code for an interactive fiction parser
based on Inform's. It's really old code, and I never used it in an
actual game (let alone one based on POE), but maybe you can use it for
something.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE::Event and the death of call()
On Thu, Jun 21, 2001 at 04:55:46PM -0400, [EMAIL PROTECTED] wrote:
> I hate call(). I really do. It makes code un-POE-like. And it can't
> work w/ IKC. However, it's really the best way to get an answer back. In
> IKC, you have to do $kernel->post(IKC=>'call', $specifier=>[params],
> 'callback_state') but this isn't compatible with session subscription.
call() sucks, but it lets wheels pass on their synchronous input
events to the sessions which own them. As far as I know, that's the
only valid reason to use it.
Not entirely true. I use it extensively in the crossword server xwws
(somewhere at poe.perl.org), but I'd rather not have had to. Now that
postbacks exist, the mere act of sending an event can keep the sender
alive at least until it's delivered.
Although postbacks across the inter-process boundary are going to fail
unless the gateway component holds onto them.
Speaking of IKC woes, RPC and cluster computing background papers may
explain some of the hardships you have/will encounter. I suppose
you've already done the research, but I'm suggesting on the off chance
it could help.
> So, how about also allowing a hash ref... or POE::Event object as a
> specifier for event addresses?
> {
> to=>'some_session/some_event',
> sender=>$_[SENDER],
> reply=>'callback_event'
> errors_to=>'error_event' # temporary monitor
> }
This looks like the POE::Message prototype I sent you a week or so
ago. You're the unofficial interoperability (i14y?) pumpking, so I
thought I'd run it past you first.
This would also eliminate ARG0..ARG9 for many high-level things, which
would make mjd happy. His comments on the subject prompted the
ARG0..ARG9 depreciation in the TODO file (still only in the "hey, this
could be a good idea" phase. no scary breakage yet!), and ultimately
POE::Message.
> of course, all of these could be IKC specifiers.
POE::Message would also work in stock POE. I imagined adding hooks to
the alias/id resolver to pass messages to unknown destinations to a
resolver/gateway component, if such a beast was loaded.
> This way, we can ignore call() when playing with IKC. We can deprecate
> call(). We can live free!
Can't depreciate call() in the general sense, sorry. Wheels need it.
But as Artur has suggested before on the topic, we can depreciate and
prevent it from working on any other session but the current one.
Basically we'd remove the SESSION parameter and have it default to the
current one.
Cue the pitchforks and torches.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Introspection
On Thu, Jun 21, 2001 at 05:06:51PM -0400, [EMAIL PROTECTED] wrote: > I don't think POE has much of this. I would like to get a list of all > current sessions (probably a list of IDs), then query for, with aliases > and current states. Something like : > > @ids=$kernel->session_list(); Useful and not without precedent. See /bin/ps almost anywhere. > @events=$kernel->session_evnets($ids[0]); I'm against this one. Sessions' privacy has always been a major design goal. If a session wants you to know what's in it, it should include something to tell you when you ask nicely. That way, also, you don't find things it never wanted you to see in the first place. And anyway, sessions keep to themselves. The Kernel doesn't know which events they can handle. > @aliases=$kernel->alias_list($ids[0]); # does this currently work? alias_list() should work in 0.1403 or so. Maybe I haven't released it yet; check the CHANGES file. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more
On Thu, Jun 21, 2001 at 11:51:45PM -0400, Matt Cashner wrote: > On 21 Jun 2001, Fletch wrote: > > > This brings up sone of my big recent questions: Are there any > > plans for some sort of POE - Stem convergence? > > interoperability for this point. tho i still maintain that stem can be > written to be a layer on top of poe. which would rock. but yeah, we > talked a lot at yapc about this project. leolo is the big expert on > this. I had thought about grafting stem onto poe, but I don't have time for it. Anyway, while it may be worth some geek points, it would be fruitless without Uri's blessing. I don't think he'd be too keen on it: he was dead set against the idea when I suggested it a year or two ago. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more
On Fri, Jun 22, 2001 at 09:17:19AM -0400, Matt Cashner wrote: > On Fri, 22 Jun 2001, Rocco Caputo wrote: > > > fruitless without Uri's blessing. > > sure it would be. we'd have the niftiness of stem (which does do some > cool stuff) in poe. blessings or not, that's a pretty good goal. "Fruitless" may not have been the right word. How about "frustrating"? Importing stem niftiness into poe might be fun, but it has a couple potential problems: Someone would have to track stem's changes and keep poe up to date. Bleah! Don't let it be me. There may be scars where the two systems are attached. Consider postbacks and the boundaries between poe and Gtk or Tk. While you're considering that, try to find a cleaner solution. :) Philip seems to be taking a different approach, which has some plusses. Write an object system for poe, and design stem compatibility into it. That smooths over the scars between paradigms and reduces the amount of project tracking needed. If he's careful, his object system will cooperate with the one I prototyped in 1998. A third route is to port stem to poe's event loop. "Fruitless" would be a good word to describe a poe/stem (post'em?) hybrid if Uri won't accept it. Trying to maintain it anyway brings us back to "frustrating". > > I don't think he'd be too keen on > > it: he was dead set against the idea when I suggested it a year or two > > ago. > > a few words brought this back towards a sensible middle. poe on nt. > stem doesnt work on nt. poe does. poe works most anywhere, iirc. > that's a huge gain for stem. esp if we're doing the coding and uri > isnt paying us :) This implies that a stem/poe (stempo?) hybrid will be written and accepted, but that begs two questions: A hybrid system seems important for Stem Systems' flagship product. Why won't he be working on it? Essentially you'll be porting his product to Windows/NT. Why won't he compensate you for your time? -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
yield() must die?
[Rocco wrote] > >> Cue the pitchforks and torches. > 01-06-22 02.04, skrev [EMAIL PROTECTED] på [EMAIL PROTECTED] följande: > > yield() is misnamed! > > > > /me runs, ducks and hides. On Sat, Jun 23, 2001 at 03:08:36PM +0200, Artur Bergman wrote: > > Yes, if we are on the topic of breakage, LETS RENAME YIELD!! > > yield is probobly the most confusingly named function in POE, it is in all > other contexts used to tell the scheduler that you can don't realy need the > CPU right now, that is not what yield does in POE. I have never found a good name for this function. If you have one, I will happily document it in the TODO file. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Official Object Layer Design Guidelines
Multiple object layers have been possible for as long as multiple sessions have been. Your object layer can do anything you want it to, provided you have the talent, patience, and perseverance to write the code. You can build castles in the sky, but first you must invent strong enough air. A lower level poe layer will never require a higher level one. Poe has contributed to the evolution of people and programs, but I will not allow it to become monolithic. Every new layer should be more fun to use than the one just below it. You've done something wrong if your object layer isn't more fun that using poe itself. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Scripting, semaphores and relationships
On Tue, Jun 26, 2001 at 09:35:39PM -0400, [EMAIL PROTECTED] wrote: > The idea of POE scripting has been floating around for some time now. > Here are some other ideas on it. [...] > Another way of looking at this is to have semaphores between each state. > () get_sequence (A) > (A) validate (B) > (B) create_dir (C) > (B) mail_buyer (C) > (B) mail_merchant (C) > (3C) send_response () [...] It also looks like a makefile: all: send_response get_sequence: &get_a_sequence validate: get_sequence &validate_whatever create_dir: validate &make_directory mail_buyer: validate &send_email($buyer) mail_merchant: validate &send_email($merchant) send_response: create_dir mail_buyer mail_merchant &send_response I guess ARG0 (the pseudo-heap) would be where all these steps accumulate information like the sequence, buyer, and merchant? Anyway, I've attached some code. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net depends.perl.gz
Re: Beyond IKC/monitor : SENDER, session death and more
On Wed, Jun 27, 2001 at 10:13:22AM -0400, [EMAIL PROTECTED] wrote: > > On 27-Jun-2001 Artur Bergman wrote: > > Ok, could somone tell me, what do you people want to monitor. I am lost. > > The list again, with annotations : > > Monitor triggers are one of : [... session monitors ...] Monitoring and exceptions should watch objects, not sessions. The code to do it belongs in the object layer. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more
On Wed, Jun 27, 2001 at 11:13:39AM +0200, [EMAIL PROTECTED] wrote: > On Wed, Jun 27, 2001 at 09:51:50AM +0200, Artur Bergman wrote: > > 01-06-27 07.54, skrev [EMAIL PROTECTED] på [EMAIL PROTECTED] följande: [...] > > Aren't those hooks supposed to be in the object layer, as POE has no concept > > of objects. > > Sessions have most of the properties objects have: aatributes, methods, > inheritance, ... > > but these monitoring features are probably useful, although quite low level :( Don't confuse sessions and objects. They are entirely different things with completely separate purposes. They live in totally different design spaces (layers) and have very little at all to do with each other. Sessions have no inherent inheritance. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more
On Wed, Jun 27, 2001 at 11:21:45AM -0400, [EMAIL PROTECTED] wrote: > > On 27-Jun-2001 Rocco Caputo wrote: > > On Wed, Jun 27, 2001 at 10:13:22AM -0400, [EMAIL PROTECTED] wrote: > >> > >> On 27-Jun-2001 Artur Bergman wrote: > >> > Ok, could somone tell me, what do you people want to monitor. I am > >> > lost. > >> > >> The list again, with annotations : > >> > >> Monitor triggers are one of : > > [... session monitors ...] > > > > Monitoring and exceptions should watch objects, not sessions. The > > code to do it belongs in the object layer. > > ...because it would add overhead to signal and IO event delivery. The > collory is that POE shouldn't be used to deliver messages between objects. Of course it adds overhead. The alternative is a monolithic system without clearly defined and separated subsystems. That would suck. There would be only one kind of Kernel, and only one sort of Session, and only one object layer. They would all be inextricably intertwined and a huge mess to maintain. Your corollary is false. Poe events are a low level transport for high level object messages. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more
On Wed, Jun 27, 2001 at 12:50:48PM -0400, [EMAIL PROTECTED] wrote: > > On 27-Jun-2001 Rocco Caputo wrote: > > Of course it adds overhead. The alternative is a monolithic system > > without clearly defined and separated subsystems. That would suck. > > There would be only one kind of Kernel, and only one sort of Session, > > and only one object layer. They would all be inextricably intertwined > > and a huge mess to maintain. > > I've just taken a longish walk and thought a bit. What I realised is > that "Yes, People think Sessions are Objects". Sessions can do > inheritance (via object_states and package_states). Each session can have > instance variables (via $heap). At the very least, POE::Components look > very much like Objects. > > Let's try to break this association. > > My view of the object layer is that each Object would have a Session > associated with it that would handle poe-related stuff. I think you see > it as one Session dealing with all the Objects. Objects have to interact > with the POE kernel (aka call back to POE kernel). > > Let me twiddle some code here. > > > Your corollary is false. Poe events are a low level transport for > > high level object messages. > > I disagree. When you start using POE events to transport messages, you > run into all the problems we've been talking about and the need for > monitoring, which you take exception to. I see Sessions as sessions. That's why I originally named them that. One session can invoke several objects, and an object environment can have several sessions at once. 1 kernel -> many environments -> many sessions per environment -> many objects per session Objects don't interact directly with the Kernel. They talk amongst themselves with functions provided by the object layer. The object layer talks to the Kernel transparently on behalf of objects, as necessary. This is part of making objects more fun than sessions. Since all object/kernel interaction goes through the object layer, it can monitor everything that happens. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: create(options=>{}) not working as expected
On Wed, Jun 27, 2001 at 03:16:40AM -0400, [EMAIL PROTECTED] wrote: > Here's a patch : > > diff -u -r1.63 Session.pm > --- Session.pm 2001/05/28 06:42:01 1.63 > +++ Session.pm 2001/06/27 07:15:51 [...] It'll be in the next version. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Addressing once again
On Fri, Jun 29, 2001 at 12:54:30PM -0400, [EMAIL PROTECTED] wrote: > For those of you who aren't on IRC, here is a list of different schemes > for doing addressing in POE and beyond. > > http://pied.nu/Perl/addresses.txt > > Anyone have other ideas? Any preferences? URI style isn't transparent. Ideally, a program shouldn't need to know whether it's talking to a poe thingy or a stem thingy, so everything up to the colon gets in the way. I'm partial to kernel/session/event, where kernel/ and kernel/session can just be left off if they're not needed: kernel/session/event session/event event There's only one reserved character, and the number of fields in the address determines how far away its destination is. I think it scales, too: universe/galaxy/solarsystem/planet/cluster/kernel/session/event Oh, this is just a bang path in disguise. Whee! "/" is a little easier to type than "!", anyway. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
apology to Philip and the list
I apologize for my behavior last week. I had no idea what Philip was talking about until we swapped pictures of our ideas. Please disregard most of what I said about object layers; it doesn't really apply to what he's doing. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Commands in POE::Component::IRC not being executed timely
t.PRIVMSG. 0x0070 236d 6a64 203a 646e 676e 6f74 2073 6179#mjd.:dngnot.say 0x0080 7320 226f 6e65 206c 6167 2063 6865 636bs."one.lag.check 0x0090 220d 0a".. Here's a housekeeping ping later on in the bot's session. The timestamp inside the packet matches the time it was transmitted. 13:15:26.989748 206.251.198.172.2627 > 199.245.105.172.6667: [...] [...] 0x0030 45e0 171c 5052 4956 4d53 4720 236d 6a64E...PRIVMSG.#mjd 0x0040 203a 484f 5553 454b 4545 5049 4e47 204d.:HOUSEKEEPING.M 0x0050 6f6e 204a 756c 2020 3220 3133 3a31 353aon.Jul..2.13:15: 0x0060 3236 2032 3030 310d 0a0d 0a26.2001 But it takes almost half a minute to return! 13:15:53.384472 195.82.114.160.6667 > 206.251.198.172.elan: [...] [...] 0x0050 616d 692d 464c 2d32 2d31 3732 2e6e 6574ami-FL-2-172.net 0x0060 7275 732e 6e65 7420 5052 4956 4d53 4720rus.net.PRIVMSG. 0x0070 236d 6a64 203a 484f 5553 454b 4545 5049#mjd.:HOUSEKEEPI 0x0080 4e47 204d 6f6e 204a 756c 2020 3220 3133NG.Mon.Jul..2.13 0x0090 3a31 353a 3236 2032 3030 310d 0a :15:26.2001.. So it looks like POE's ok. Yay! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Beyond IKC/monitor : SENDER, session death and more (fwd)
On Wed, Jun 27, 2001 at 09:30:55AM -0400, Matt Cashner wrote: > not sure why this didnt make it to the list as well. > > -- Forwarded message -- > From: [EMAIL PROTECTED] > To: Matt Cashner <[EMAIL PROTECTED]> > Subject: Re: Beyond IKC/monitor : SENDER, session death and more > Date: Wed, 27 Jun 2001 14:58:04 +0200 > > On Wed, Jun 27, 2001 at 08:11:14AM -0400, Matt Cashner wrote: > > On Wed, 27 Jun 2001, Artur Bergman wrote: > > > > > Ok, could somone tell me, what do you people want to monitor. I am lost. > > > > the POE environment. what states are being called when with what > > parameters. what's going on in the POE core, etc. and not just in nifty > > printed statements. i'd like to have that data to do whatever i want > > with it. > > > > picture the ability to take a snapshot of the POE environment, then load > > that up and be able to replay your session from start to finish. > > that would be cool, but is _not_ easy. it would be fine if someone could > write somethings (or a draft at least) how taking snapshots of POE apps > could work. note that it would include saving runtime/host dependent things > like file handles, which need more work. alarms are a bit of work too ... :/ > > > torvald $poe_kernel is root for all of POE's data. If you Data::Dumper that, for values of Data::Dumper that reconstitute source code from opcodes and stuff, you get everything POE knows about. That covers everything in POE::Kernel (queues, select bits, and whatever) and reaches into HEAPs and everything within them. Restarting files and stuff (like graphical toolkits) are left as a very hard exercise for the reader. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: batch removal functions
On Fri, Jun 01, 2001 at 01:13:53PM -0400, [EMAIL PROTECTED] wrote: > > Maybe some sorta meta-remover? Kills all selects, aliases, alarms, > pending events to a given session, thereby causing the session to succumb > to garbage collection? POE::NFA has an explicit stop method. $_[MACHINE]->stop() will do it. > Of course, this is being "lazy" in that one can keep track of all of this > and do it oneself. However, one has to fully grok POE's GC for that. > Maybe a debug routine that would tell you why a session hasn't been GCed. TRACE_GARBAGE will enable a running trace of sessions and their reference counts, in annoying detail. It's helped many times in debugging Kernel's data structures. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
version 0.1404 is on the web
It's available from the usual places: http://poe.perl.org/ http://sf.net/projects/poe/ The Windows version is lagging because it's maintained by other people. I'll announce it separately when it's ready. This is release candidate 2 or so for version 0.15. I'm not adding new features until 0.15 is on the CPAN. Changes follow. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1404 2001.06.02 - Kirill found a bug in alarm_adjust(): it would corrupt/disorder the alarm queue. Added ASSERT_ALARMS to POE::Kernel::Select, ensuring that the alarm queue stays in order-- or ELSE! Added tests to t/02_alarms.t, tweaking the disordered alarm queue bug in alarm_adjust(). Fixed alarm_adjust(). Optimized a little in _enqueue_alarm() while I was there. Coral spotted me using "either" to refer to three things in the POE::Kernel manpage. Corrected that bit of bad grammar. If anyone else wants to pick over the rest of the documentation for errors, they'd better submit patches too. I had no idea the files in the ./lib directory were being installed. They were never meant to be, but MakeMaker was including that directory by default. Fletch pointed me to PMLIBDIRS, which I have tweaked to prevent this from happening in the future. Philip Gwyn found and patched a bug where setting (trace => 0) on a session turned tracing on. I fixed the same bug for (debug => 0), and I fixed both options in NFA.pm also. Philip Gwyn found a documentation bug in POE::Session, claiming that STATE wasn't _default in _default handlers. Fixed. Matt Cashner pointed out extraneous noise in t/00_coverage.t, which was subsequently squelched. -End-
Re: POE Dependancies
On Tue, Jul 03, 2001 at 09:33:05AM +0200, jotham wrote: > POE has a number of dependancies. And sub dependancies. It seems there is > not a complete document describing the entire dependancy tree. Correct me > if I am wrong. I do not have an internet connection at home and have been > trying to install POE. I keep finding unmentioned dependancies. The > information reguarding dependancies that is shown in the make process should > really be placed in the man pages. And perhaps the dependancies of those > dependancies. I would like to assist if I can. Dependencies are documented in the POD for POE.pm (and the resulting POE manpage). Here's what's already written on the subject. Please feel free to fix it. =head1 SYSTEM REQUIREMENTS POE's module recommendations have been codified as part of the `make test' procedure. Any missing dependencies will be reported on, and POE will refuse to test itself if critical modules aren't found. Some of POE's sample programs use fork(). They won't work wherever fork() isn't available; sorry. POE relies heavily on constants in the POSIX module. Some of the constants aren't defined by ActiveState Perl for Windows, but POE defines them itself to work around this. POE::Preprocessor needs Filter::Util::Call version 1.18 or later for source filtering. Everything else relies on POE::Preprocessor. Some of POE's sample programs require a recent IO bundle, but you get that for free with recent versions of Perl. Filter::Reference needs Storable or FreezeThaw or some other data freezer/thawer package. Storable tends to be the fastest, and so it's preferred. Compress::Zlib is needed if you want to compress frozen data. B If you're using Filter::Reference to pass data to another machine, make sure every machine has the same versions of the same libraries. Subtle differences, even in different versions of modules like Storable, can cause mysterious errors when data is reconstituted at the receiving end. Whe all else fails, upgrade to the latest versions. Filter::HTTPD uses a small world of modules including HTTP::Status; HTTP::Request; HTTP::Date and URI::URL. The httpd.perl sample program uses Filter::HTTPD, which uses all that other stuff. Wheel::Curses requires the Curses module, which in turn requires some sort of curses library. =cut -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Addressing once again
On Tue, Jul 03, 2001 at 11:54:42PM -0400, [EMAIL PROTECTED] wrote:
>
> On 29-Jun-2001 Rocco Caputo wrote:
> > On Fri, Jun 29, 2001 at 12:54:30PM -0400, [EMAIL PROTECTED] wrote:
> >> For those of you who aren't on IRC, here is a list of different schemes
> >> for doing addressing in POE and beyond.
> >>
> >> http://pied.nu/Perl/addresses.txt
> >>
> >> Anyone have other ideas? Any preferences?
> >
> > URI style isn't transparent. Ideally, a program shouldn't need to
> > know whether it's talking to a poe thingy or a stem thingy, so
> > everything up to the colon gets in the way.
Yeah! I agree! With myself! Me too!
> > I'm partial to kernel/session/event, where kernel/ and kernel/session
> > can just be left off if they're not needed:
> >
> > kernel/session/event
> > session/event
> > event
>
> Given a plain scallar, taken out of context (say in the doco, or in email,
> or in a tuple-space), how do you tell if it's a session, kernel or event?
>
> session/
> kernel//
No kernel or event mentioned:
"/session/"
No session or event mentioned:
"kernel//"
Same as yield:
"//" or just ""
Machines can read it; why can't people? I understand, though: at
first glance, the reader's got to do a little more thinking.
Positional fields suck, especially when paths like that get long (just
what does "/milkyway/sol/earth/n-america/dngor//" mean?). That's a
point scored for that ugly "/tag=value/tag=value" format.
Anyway, here's how it's parsed. Mind you, I just woke up and this is
just a little better than pseudocode.
sub parse_address {
my $address = shift;
my ($kernel, $session, $event);
my @address = split /\//, $address;
if (@address == 0) {
# Pathological case: yield() by another name.
($kernel, $session, $event) = ($my_kernel, $my_session, $my_event);
}
elsif (@address == 1) {
($kernel, $session, $event) = ($my_kernel, $my_session, @address);
}
elsif (@address == 2) {
($kernel, $session, $event) = ($my_kernel, @address);
}
elsif (@address == 3) {
($kernel, $session, $event) = @address;
}
else {
croak "What you say";
}
# Empty fields are filled in with current defaults.
$kernel ||= $my_kernel;
$session ||= $my_session;
$event ||= $my_event;
# Do whatever with it.
...;
}
[...]
> > I think it scales, too:
> > universe/galaxy/solarsystem/planet/cluster/kernel/session/event
> >
> > Oh, this is just a bang path in disguise. Whee! "/" is a little
> > easier to type than "!", anyway.
>
> IHNJ, IJLS BANG PATH
Bang! Path! Bang! Path! Bang! Path! Bang! Path! Smock! Smock! Smock!
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE::Filter::Reference patch
Ok! Now that I know you wrote the original code, I've gone ahead and
patched it. Expect it in 0.15, which I expect to release in the next
few days.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
On Thu, Jul 12, 2001 at 08:37:16PM -0400, [EMAIL PROTECTED] wrote:
> POE::FIlter::Reference does the following to check if the package $freezer
> is loaded :
> exists $::{$freezer.'::'}
>
> and the following to load the package
> eval { eval {require "$freezer.pm"; import $freezer ();};
>
>
> This fails pityfully if $freezer contains ::. The following patch cures
> this. I don't know if s(::)(/)g; is compatible with Mac OS, though.
> Maybe we should just eval "use $freezer ();";
>
> -Philip
>
> --- POE/Filter/Reference.pm 2000/12/26 06:14:12 1.20
> +++ POE/Filter/Reference.pm 2001/07/13 00:31:31
> @@ -56,8 +56,20 @@
[...]
Re: POE::Filter::Reference patch
I had planned to release 0.15 to PAUSE today, but stuff came up. I'm tidying up TODO, README and CHANGES today, and it should be uploadable tomorrow or Monday. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net On Sat, Jul 14, 2001 at 03:29:29PM -0400, [EMAIL PROTECTED] wrote: > > On 13-Jul-2001 Rocco Caputo wrote: > > Ok! Now that I know you wrote the original code, I've gone ahead and > > patched it. Expect it in 0.15, which I expect to release in the next > > few days. > > BTW, pudge says that require "Foo/Bar.pm" will work on Mac OS. So the > only possible problem would be VMS. :) > > Also, I was wondering if/when 0.15 would go to CPAN. Matt has been > muttering about stable versions vs bleadPOE and wanting to deploy an > application. And IKC 0.13 uses features that will are only present in > POE 0.15. Such as : a pure-perl serializer, called > POE::Component::IKC::Freezer. Note how this will fail to work with POE > 0.14. > > -Philip >
Version 0.15 is on the web and PAUSE
[This announcement sounds a little odd because it's also going to be posted to comp.lang.perl.announce.] Good morning. It's my pleasure to announce that POE 0.15 has been uploaded to the PAUSE. It will arrive at your favorite CPAN mirror after the customary propagation delay. It's available from two web sites right now, if you'd rather not wait for it to reach the CPAN site of your choice: POE's main web site: http://poe.perl.org/ SourceForge: http://sf.net/projects/poe/ It's been some 80 days and four development releases since 0.14. Thanks to everyone who sent in feedback and patches. If you would like to receive announcements of POE's development releases, please send a message to <[EMAIL PROTECTED]>. You will receive instructions for subscribing to POE's mailing list. Change highlights since 0.14: * Added a TODO file to the distribution. This is part changes roadmap and mostly a feature wishlist. * A second alarms interface. It's a little more complex than the original one, but it gives programs more control over timers. * XyzState parameters in wheels have been renamed to XyzEvent. This doesn't break existing code yet, but it is expected to in September. See the TODO file for exact breakage dates. * Documentation and installation fixes. POE won't clobber Devel::Trace anymore. * Removed use of features specific to perl 5.6.1. POE should once again be compatible with perl 5.004_05 and possibly older. * Better memory leak checking, and a leak fix in the signals code. * Better dependency checking and more graceful failure in the face of adversity. * Better Win32 support. Instructions for installing POE with ActiveState's PPM. You can read more about this, historical, and future releases on the web: The full CHANGES file: http://poe.perl.org/poedown/CHANGES The full README file : http://poe.perl.org/poedown/README The full TODO file : http://poe.perl.org/poedown/TODO Thanks for reading! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: [PATH] smallish bug in POE/Filter/HTTPD.pm
On Tue, Jul 17, 2001 at 04:47:45PM +0200, Anton Berezin wrote: > Hi, > > I am not sure this is the proper list to send bug reports to, but > nevertheless: [patch removed] > Bug explanation: for sufficiently large POST requests provided that > content contained consequtive newlines, the repeatable deletion of the > content data occurred; thus, the content_length bytes of data were > never read from the network (assuming the correct request). > > The fix, obviously, removes the header chunk from the accumulated buffer > only once, as soon as the end of the header has been detected. This patch looks good. I've committed it to CVS, and it'll be in the next release. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE Garbage Collection
On Tue, Jul 17, 2001 at 11:35:52AM -0700, Todd Caine wrote: > Hello, > > I'm writing a distributed application using POE. The > program uses POE::Wheel::SocketFactory and then on success > it uses POE::Wheel::ReadWrite to handle the socket. After a > successful connection occurs the SuccessState is called and > is passed my socket and wheel_id that created the socket. > Normally I just need to send a message and then disconnect > the socket. I've been creating a ReadWrite wheel with the > new socket and then stuffing the readwrite wheel_id in the > heap along with the host and port, like: [...] My first guess is an errant copy of $wheel is being kept somewhere. I'd like to see more of the program before pinning blame anywhere. If you could mail a more complete listing off the mailing list, I'll try to spot the problem. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Preforked server where only children process requests?
On Thu, Jul 19, 2001 at 04:03:24PM +0200, Anton Berezin wrote:
> Hi,
>
> What is the easiest way to achieve this goal, so that the master process
> will only provide watchdog functionality?
>
> It seems to me that it might be enough to do just that (the diff is
> relative to the samples/preforkedserver.perl), but I am not sure:
>
> --- preforkedserver.perl.orig Thu Jul 19 16:01:35 2001
> +++ preforkedserver.perl Thu Jul 19 16:02:11 2001
> @@ -154,10 +154,12 @@
> # change behavior for children
>$heap->{'is a child'} = 0;
> # fork the initial set of children
> - foreach (2..$processes) {
> + foreach (1..$processes) {
> # yield() posts events to this session
> $kernel->yield('fork');
>}
> +
> + delete $heap->{wheel};
>
>DEBUG && print "$$: master server has started\n";
> }
>
> Am I right?
Partly, I think. If I recall correctly, the child processes
eventually exit, requiring the parent to fork new ones. If you've
deleted the wheel in the parent, though, the new children will also
not have it. They won't listen for connections either, and eventually
your server will stop responding. It might go so far as to rapidly
spawn children which just exit, and that would be bad for overall
system performance. :)
The easiest workaround I can see is to have the parent process create
a listening socket (probably with IO::Socket::INET) and keep a copy of
it in its HEAP. Each child processe would immediately start a
ListenAccept wheel on the saved socket as their first task.
Mind you, the child processes don't have to exit if they don't leak
resources. I modelled the idea after Apache, which recycled child
processes now and then to prevent runaway daemons.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Preforked server where only children process requests?
On Thu, Jul 19, 2001 at 04:59:06PM +0200, Anton Berezin wrote:
[...]
> What about preventing the master process from destroying itself? Right
> now I can only come up with:
>
> In master's _start:
>
> $kernel->yield('sleeping_state');
>
>sub sleeping_state
>{
> ...
> $kernel->delay('sleeping_state', SOME_TIME);
>}
>
> There should be some kind of canonical (for POE) way of just sitting
> there doing nothing waiting for signals.
Unfortunately there isn't. The signal handling guts were written
before I understood how they would be used, so they often don't work
the way people want them to. Bleah!
I plan to revise them (see the TODO file). Until then, your delay
loop is probably the best way to keep the parent process alive.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: POE::Wheel::SocketFactory bind to multiple IP?
On Thu, Jul 19, 2001 at 10:40:25PM -0600, Chris Fedde wrote: > Is it posible for the POE::Wheel::SocketFactory to bind to more than one IP > address or does that reqire multiple factories? It can if they're all on the same subnet. A BindAddress of 10.1.2.0 should bind a socket factory to 10.1.2.0/24. If you mean several separate bind() calls, each to a completely different address, no. I didn't know that's possible. If it is, I can extend SocketFactory to accept a list reference for bind addresses: BindAddress => [ '10.1.2.3', '10.2,4,6', '10.3.6.9' ] -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: preforked server revisited
On Mon, Jul 23, 2001 at 01:34:38PM +0200, Anton Berezin wrote: > Hi, > > What is the reason for posting _stop event when a child decides it has > to die after it processes a connection? It deletes its wheel anyway, > one line above the yield() call, so _stop is delivered twice: once by > yield(), and once by the normal cleanup procedure. [patch removed] It works with your patch. Thanks! This will be in 0.1501 when it's released. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: local IP address from SocketFactory?
On Mon, Jul 23, 2001 at 01:00:46PM -0600, Chris Fedde wrote: > It seems that the handle in ARG0 from the SuccessEvent of > POE::Wheel::SocketFactory is not an IO::Socket. > I can't find any way for the session that is handling that event to get > arbitrary arguments. Am I just missing something obvious? It's a plain filehandle, really. You can call builtin functions on it: my $socket = $_[ARG0]; my ($local_port, $local_address) = getsockname($socket); print( "my side of the socket is at ", gethostbyaddr($local_address, AF_INET), # assumes INET " [", inet_ntoa($local_address), "] port $local_port\n" ); If IO::Socket is just a wrapper for socket handles, you can bless them into that package. I don't know if this works. my $socket = bless $_[ARG0], 'IO::Socket'; or my $socket = bless $_[ARG0], 'IO::Socket::INET'; -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
POE 0.15 PPD and hypertext docs are now online
Douglas Couch has built and uploaded the ActiveState PPD for POE 0.15, and it should be available (along with installation instructions) from <http://poe.sf.net/>. Doug's also uploaded a hypertext version of the documentation, which is available at the same location. Thanks again, Doug! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Win32 report
On Tue, Jul 24, 2001 at 01:28:15PM -0400, [EMAIL PROTECTED] wrote: > [...] > Well, POE already "works" under win98. Just that some of the tests fail. > I don't think we should expend too much effort to get everything working, > but if we could skip those tests and document it, it would look much > better. I'd like to get as much working as can be done in plain old perl. Otherwise, I can't argue. As perl's README.os2 says, "OS/2 is not Unix", and neither's Win32, and nobody should really expect either to be. Expect me to take a brief, shallow stab at fixing some of those warnings. Any day now! > Also, IKC also "works" under win98, but causes an annoying warning at > shutdown. That sucks. Which annoying warning? I think you told me once, but I've forgotten. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: Win32 report
On Tue, Jul 24, 2001 at 01:19:14AM -0400, [EMAIL PROTECTED] wrote:
> I had access to a win32 computer last week, so I tested POE. Here's my
> results :
[...]
> Reading dependency hints from NEEDS.
> Gathering files from MANIFEST.
> Building dependency tree.
> IO::Socket was used ok, but it didn't appear in %INC at
> ./lib/deptest.perl line 328.
I imagine deptest.perl is doing something with paths that isn't
entirely portable. I'm filing this under "I need access to a Windows
system to fix it".
> 01_sessions.t*
> Prints '1..29' but nothing else. Cookie crumbs reveal that it dies w/o
> warning in POE::Kernel::run, specifically substrate_main_loop, which I
> didn't dig into.
That test uses system signals, which Windows doesn't support. The
signals sub-tests will be skipped from now on when ($^O eq 'MSWin32').
I forsee it working in the future.
> 04_selects.t* hangs after ok 1
Hrm. I don't know why. Chalk another up to "I need access to a
Windows system".
> 08_errors.t*Causes an illegal page fault
Test 8 causes errors and makes sure they return proper values.
Sometimes it causes outright die within eval, and it expects to
continue beyond that. It also loads POE::Kernel a few times, wiping
out the symbols in that package between each try. I imagine AS Perl
is not enjoying all that abuse.
I might be able to hunt down just what in 08_errors.t is causing the
page fault, but "I need access to a Windows system" again.
> 14_wheels_ft.t*
> select error: Bad file descriptor at macro substrate_main_loop (line 89)
> invoked from C:/Philip/perl/site/lib/POE/Kernel.pm line 1153
> POE::Kernel::run('POE::Kernel=ARRAY(0x1cf9610)') called at
> t/14_wheels_ft.t line 205
More testing needed.
> 22_wheel_run.t*
> The getpriority() function is unimplemented at
> C:/Philip/perl/site/lib/POE/Wheel/Run.pm line 231.
> then hangs
Wrapped getpriority() and setpriority() in eval, and will only call
them if a priority delta is specified. This test should work in the
future.
> NB : I probably won't have the computer for much longer, so I won't be
> able to debug this furthur :(
I should check out the newest bochs or something and see if I can
install enough of an emulator to get Win32 running.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: W2K and POE 0.15
On Tue, Jul 24, 2001 at 02:22:47PM -0700, Wilkinson, Mike wrote: > > Using nmake -i test, I was able to get the following output. Tests > 04_selects.t, 19_filterchange.t and 22_wheel_run.t where skipped, due to > hanging. > > If there is any particular results/output you want tested on W2K, just let > me know. Can you enable TRACE_GATHER in lib/deptest.perl, run that, and mail me (not the list) the STDERR output? That should tell me why it's dying with "... was used ok, but didn't appear in %INC" errors. > t\01_sessions...dubious > Test returned status 14 (wstat 3584, 0xe00) Should be fixed in 0.1501 (and on the CVS tree sometime today). > t\08_errors.ok 1/26Subroutine EWOULDBLOCK redefined at > C:/POE-0.15/blib/ > lib/POE/Kernel.pm line 6 > Subroutine F_GETFL redefined at C:/POE-0.15/blib/lib/POE/Kernel.pm line 6 > Subroutine F_SETFL redefined at C:/POE-0.15/blib/lib/POE/Kernel.pm line 6 > Subroutine EINPROGRESS redefined at C:/POE-0.15/blib/lib/POE/Kernel.pm line > 6 > t\08_errors.ok 2/26Subroutine EWOULDBLOCK redefined at Excellent! I've added F_GETFL, F_SETFL, EINPROGRESS, and EWOULDBLOCK to the list of POE::Kernel symbols that need to be cleared out between tests. Maybe this will work better and/or not page fault. [ Tests 4, 14, 19, and 22 fail ] These tests all use Pipe::(One|Two)Way, so maybe the pipe's returning something which select() won't work on. Looking into the pipe constructors, they try socketpair() on Windows systems. Perhaps Windows is creating sockets with socketpair() that aren't truly sockets? I've changed the pipes to always use IO::Socket::INET on Windows systems, so maybe these tests will be fixed. [ test summary ] Excellent! I'll add this to the README for Windows. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: W2K and POE 0.15
On Wed, Jul 25, 2001 at 05:22:39PM +0200, Arthur Bergman wrote: > 01-07-25 17.19, skrev Rocco Caputo på [EMAIL PROTECTED] följande: > > > These tests all use Pipe::(One|Two)Way, so maybe the pipe's returning > > something which select() won't work on. Looking into the pipe > > constructors, they try socketpair() on Windows systems. Perhaps > > Pipes on windows, and filehandles to files using OPEN, cannot be > selected on. Understood. On systems that can handle it, Pipe::TwoWay tries socketpair(), pipe() and finally IO::Socket::INET if the other two fail. On Windows, it skipped pipe() because that doesn't work. My guess is that socketpair() is "working" but returning filehandles which aren't actually sockets, so select() fails with a bad file descriptor later on. I've worked around the problem by also skipping socketpair() on Windows. I can back out the change if that doesn't fix it, but all the "bad file descriptor" failures did coincide with Pipe::(One|Two)Way, so it's probably something to do with them. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Windows fixes are in CVS
A handful of tiny Windows compatibility changes have been committed to CVS. Instructions for getting updates from CVS are at <http://sf.net/cvs/?group=15660>. All the tests pass on FreeBSD, anyway. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: 0.15 and 5.004_05
On Wed, Jul 25, 2001 at 03:55:49PM -0400, [EMAIL PROTECTED] wrote: > t/18_filter_lineFAILED tests 26-31 > Failed 6/47 tests, 87.23% okay > > skip 26 # compiled regexps not supported [more of the same] > Shouldn't this be > ok 26 # skipped : reason Yes, it should, and I've committed a patch for it. Thanks! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
version 0.1501 is on the web
Or it will be as soon as the upload is done. As usual, it's available from one of two sites: http://poe.perl.org/ http://sf.net/projects/poe/ This version contains a lot of little changes throughout several files. I recommend against using it in a production environment, even though all the tests pass on my development system. Please try it in production, though. Many of the changes will enable fixes for two long-standing problems: 1. The lack of input flow control. 2. Race conditions while switching filters. Filter switching may already be fixed in this version, although I haven't written a test case for it yet. The complete changes from 0.15 to 0.1501 are below. Thanks for using POE. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net 0.1501 2001-07-27 - POE::Filter::HTTPD would corrupt long requests (ones which need to be read by more than one get() call). Anton Berezin spotted the problem and patched it. Added POE::Session::ASSERT_DEFAULT (see POE::Kernel::ASSERT_DEFAULT for an explanation), and POE::Session::ASSERT_STATES. The STATES assertion turns on "debug" options for POE::Session instances by default. With one assertion, misspelled state names are caught in an entire program. ASSERT_STATES isn't necessary for POE::NFA because that variation of POE::Session dies on bad events. Fixed Solaris 8 test results in README. Thanks, dynweb! Documented in TODO: An alternative design for signal propagation and handling. Documented in TODO: An alternative to yield(). Fixed ARG0..ARG9 offsets so they match in POE::Session and POE::NFA, which they must do or bad things happen. Removed an extra _stop in samples/preforkedserver.perl. The following Windows fixes are in response to some fine testing by Philip Gwyn and Mike Wilkinson. Wrap Wheel::Run's getpriority() and setpriority() calls in eval, and check their return values. Hopefully Wheel::Run won't die terribly on systems that don't support these calls. Update the README with more detailed Windows testing information. Change Pipe::(One|Two)Way to always use IO::Socket::INET on Windows systems. I suspect socketpair() is succeeding under Windows but creating "sockets" which select() doesn't recognize as sockets. Fix t/01_sessions.t to skip its signals tests on Windows. Windows' signals support is, erm, lacking at this time. Add Windows compatibility constants to the symbols which need to be cleaned out from POE::Kernel's namespace in t/08_errors.t. Make runtime errors in macros point to the absolute line in the file where the macro was defined, rather than the offset into the macro itself. Developers can jump directly to the offending code in the file rather than count lines in the macro. Turn const and enum constants in POE::Session and POE::NFA back into constant subs. This is a step towards inheritable sessions, now that @ISA and method calls aren't real slow anymore. There may still be a performance hit in legacy versions of Perl, but the code will still work there. Turn DEB_DESTROY into TRACE_DESTROY in POE::Session and POE::NFA, so it's more like all the rest. I didn't actually document it, though. :) Tweak lib/deptest.perl to print a more useful diagnostic message for not finding a module in %INC although it loaded okay. Fix test 18's skips for unsupported compiled regexps in older perl versions (namely 5.004_05). Add get_one_start() and get_one() to the following filters: Block, Grep, Line, Map, RecordBlock, Reference, and Stream. Switching between these filters should be robust now. Add support for get_one_start() and get_one() to Wheel::ReadWrite. It only uses these methods if the input wheel supports them. Otherwise it falls back to the older, faster, but more dangerous get(). Tweak language for existing depreciations in TODO, so the schedule of changes is more explicit. Please don't misunderstand. Develop the ideas for fixing filter changing in TODO. Set up a checklist, and actually begin implementing stuff. Tested error conditions in several modules, prompting some changes. Made the errors for Session->new() parameters a little more descriptive. Made misuse of Filter::HTTPD->get_pending() croak instead of warn. Made bad constructor parameters in POE::Wheel::Run fatal. Added a test for Component::Server::TCP's "shutdown" event handler. Added get_one_start() and get_one() tests for Filter::Block. Added get_one_start() and get_pending() tests for Filter::Reference. Added get_one_start(), get_one(), and get_pending() tests for Filter::Map and Filter::Grep. Added tests for Filter::Stackable's filter stack management methods. -EOT-
Re: httpd.pm
On Fri, Jul 27, 2001 at 11:50:52PM -0400, undercut wrote: > I think this filter still could use some updating. It seems the > methods send_error, send_basic_header, and send_status_line will cause > a crash from strict refs since it calls the put method with a string > when it expects arrayref. All you have to do is send a bad request > (like 2 blank lines) and it will trigger the crash. > > Please keep up the great work. > > -- undercut I've fixed this and checked the new code into the cvs repository. The fix required a small change in the way Filter::HTTPD handles errors. Instead of crashing outright, it returns an HTTP::Response object containing the error message. I've documented a suggested use in the Filter::HTTPD manpage. If ref($request) is "HTTP::Response", just put it directly and return. Otherwise the program has received a request and can parse it as usual. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: automatic postbacks
On Mon, Apr 02, 2001 at 12:21:35AM +0200, Torvald Riegel wrote: > > what do you think about some sort of automatic postbacks? a third type of > generating an event, which would be posted to the target session. the > associated state's return value would be returned to a postback that is > specified when sending the first event. so one would use something like > $kernel->postandreply($target, $event, $self->postback(...), @args) > advantages would be that the target session would not need to care about > handling postbacks and returning values through them. one more function would > have to be maintained and postacks would need to be kept somewhere at the > event's structures. garbage collection shouldn't be a problem since > the postback would be a normal parameter otherwise. > really good would be if this return-postback could be set as another state's > return-postback. so if user() would postandreply server() but server() would > have to call worker(), the postback could be handed over to worker() and it > would reply through the postback. this would only be a variation of > postandreply i think. > i know everything could be done using postbacks given as state arguments, but > the above would make returning values simple and easier to read at the > server() side. Others have wondered about something similar, so I've added this to the TODO file. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
SUMMARY: POE::Event and the death of call()
On Thu, Jun 21, 2001 at 04:55:46PM -0400, [EMAIL PROTECTED] wrote: > I hate call(). I really do. It makes code un-POE-like. And it can't > work w/ IKC. However, it's really the best way to get an answer back. In > IKC, you have to do $kernel->post(IKC=>'call', $specifier=>[params], > 'callback_state') but this isn't compatible with session subscription. Here are the related issues I'm documenting in TODO: 1. Yield must die. a. Rename the bastard. b. Maybe move it to $session->post() 2. Call should be depreciated, possibly rewritten, and maybe even moved elsewhere. a. Call between sessions is evil and should go away. b. So call() becomes something which defaults to the current session. c. Like yield(). d. Which is also evil and should go away. e. So perhaps $session->call() 3. POE::Message (or POE::Event) is a good thing. a. It can encapsulate named parameters instead of the vaguely icky ARG0..ARG9. b. It can encapsulate several postbacks, including refcounts which keep the sender alive. c. It can encapsulate inter-Kernel routing, messaging, and directory services. d. It can encapsulate automatic postbacks and exceptions. Have I missed anything? -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: preforking server
On Sun, Jul 29, 2001 at 11:28:01PM -0700, Bill Moseley wrote: > > I'm just looking for ideas: > > I want to build a server for the swish-e search engine. This would avoid > the cost of forking and exec'ing a swish-e binary, plus avoid the startup > costs of opening and parsing the header of the swish index file(s). The > build process for swish-e builds a C library, and I have a working xs > interface. > > A number of people at the open source conference recommended POE. But, I'm > not sure if POE can help. One problem is that searches can take some time > for large indexes. So the blocking could be an issue. Also, on errors > swish calls exit(), so I'd still need to fork to protect the parent server. The first probable solution that comes to mind-- and I have to admit I don't know much about SWISH or any designs you've already worked out-- is several back ends spawned off the main server with POE::Wheel::Run. P::W::Run does the usual pipe/fork/exec for stand-alone programs. It also can execute functions in child processes with the usual stdio pipes back to the parent. In this model, the main process acts as a proxy between clients and the back-end processes. That's extra overhead you may not want. > So, I was thinking of a pre-forking (Apache like) design would be best, > especially if there was a manager that would replace children that exit(), > or could spawn/kill more children depending on load. That would avoid the > forking for each request (search), yet still protect the parent from a > child's death. This sounds better. The child processes would answer requests directly, letting the parent know which are busy so it can decide if more need to be spawned or killed. > I really like the looks of POE, but I'm not clear if POE can help. > > Any suggestions? Build your dream design on paper, ignore system requirements and limitations at first, and then find work-arounds or implementations for the sci-fi stuff until it's feasable. :) > I'm also haven't though about sharing or caching open index files between > child processes. It would be nice to avoid separate copies of the same > index file in different child processes. Does SWISH-E load the entire index file into memory? The interface seems to follow a pattern where data is iterated over on disk, but my first exposure to it was just a few minutes ago. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
