On Fri, Jun 13, 2003 at 04:19:57PM +0200, Bruno Boettcher wrote:
> Hello!
>
> again i am stuck in a surely trivial and stupid problem, showing again
> that i didn't understand a single thing about POE....
[...]
> unfortunately that event is gobbled up somewhere by some other
> session.... i suppose the POE::Component::Client::TCP thing is
> responsible for that...
If messages are being sent but not received, you can easily find them
by setting POE::Kernel::ASSERT_EVENTS, like so:
sub POE::Kernel::ASSERT_EVENTS () { 1 }
use POE;
It's important to set ASSERT_EVENTS before using POE.pm (or POE::Kernel)
so that the module will see the value when it loads.
[...]
> GENERAL QUESTIONS:
>
> This shuffled up again the fact that i still have problems understanding
> POE....
Also see http://poe.perl.org/?POE_Documentation/Beginners_Guide
> - i have several objects, they might start up their own sessions, since
> POE is somehow a global thing, i need to call the kernel run method only
> once somewhere, right?
Yes. I usually call POE::Kernel->run() after setting up the initial
objects for a program. Several of my bot programs look like this:
#!/usr/bin/perl -w
# $Id: pastebot.perl,v 1.4 2003/02/03 04:50:17 rcaputo Exp $
use strict;
use POE;
use Server::Web;
use Client::IRC;
$poe_kernel->run();
exit 0;
Server::Web and Client::IRC read configuration options and create their
objects and sessions. The configuration includes aliases for each
module, and the modules are designed to talk to each-other using those
aliases.
It's an interesting way to write programs, and I need to document it,
but the programs themselves are very bad examples of coding style.
> - events are generated and distributed randlomly to the listeners, once
> one listener claims the event, it isn't propsed to the other sessions,
> right? or is there some sort of telling that the events should be
> proposed also to the other sessions?
The English of this question is very bad. Because I can't quite
understand it, I will answer every question I think it may be.
Events are generated as real-world things happen. "This file has input
waiting." "At the event, the time will be 16:00 UTC." "The user is
vainly attempting to suspend the program with ^Z." "This child process
has closed its output filehandles."
Events also are generated when you call POE::Kernel's post(), yield(),
or signal() methods.
The post() method sends events to a session. That session may be
different from the one that calls post().
The yield() method sends events to the session that called it.
Events are queued very deterministically. They are stored in what is
essentially an array, in due-time order. Alarms and delays are usually
due in the future, so they reside later in the queue. Events
representing immediate conditions are enqueued for time(), so they
happen in more-or-less FIFO (first in, first out) order.
> - to the above question addendum, i didn't get the difference between
> post and signal, when should i use which one? in all the code i see only
> the use of post, never signal, should i use signal this time??
The signal() call is for simulating signals without using kill() or
involving the operating system.
Signals are broadcast to every session that has used sig() to listen for
them. Currently they are also broadcast to every other session, under
the _signal event, but that is deprecated and will go away soon.
Signals may be used to broadcast one event to many sessions at once.
Posted events are more point-to-point.
> - sessions like the TCP stuff and the IRC module register an alias iwth
> which it is possible to get it later on globally from the heap, how do i
> setup such a mechanism? alias isn't a recognized var of session?
Aliases are not stored in the heap. You may retrieve the aliases for a
session with $kernel->alias_list($session) but there isn't a global
registry of them.
It's assumed that you assigned the aliases to ecah session, so you know
what they are.
> - i have a job that is returning only when the wholething closes down
> (= a shell) with very slow input (a human user) that qualifies as a long
> running task... actually i run it inside a POE event handler, but
> should i use the ::Run object instead? do i cause some havoc somewhere
> by blocking the return of that event processing or doesn't it matter??
You should use POE::Wheel::ReadLine or Term::Visual. Both work without
blocking your program. Term::Visual is especially nice.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
