Scott wrote:But communication with child processes will never be synchronous, you have too many steps to go through to communicate with child processes (via pipes, or other methods, nothings going to be _RIGHT_NOW_)
[...]
If you're really only storing data, you really should use an object OR package in the ways I mentioned above. Atleast, if you have any desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing inter-session calling all together. I found the idea on the wiki. Now I'm not gonna name names, and I'm not gonna drag others in, because I am a proponent of the idea. I think inter-session calling breaks POE Design patterns. Forcing inter-session communication to be done via post()ing helps force people using the POE Framework to let POE do its thing, and stops people from doing things like creating sessions just for the sake of creating sessions.
I also have a need for inter-session calling, so I want to add my tuppence into this :-). Hopefully, my description below isn't so abstract to be non-sensical, but will convey why I need it.
I have a fairly complex system that runs various background monitoring tasks (using Wheel::Run) and also takes in requests from the network. Each new network request gains its own session for it to process all work. This work may take some time, also creating new Wheel::Runs, etc. The effect of some of the requests needs to change the frequency of the background monitoring that's going on, or needs to change some of the 'global' data that dictates the manner in which the background processing is run. There is no synchronisation/locking of global data, so the only way to do that is to ask the session owner to make the change. When that type of event happens, we need to get a cross-session event to take place. We can't use post() all the time, because sometimes we need to ensure that the change happens before anything else in the queue is fired off, else we get out-of-order processing. It's a rare thing (only need this twice, in a codebase of ~20k lines of perl), but it does happen. I cannot see (within the constraints of our architecture) how I can achieve this without inter-session call functionality.
Nick.
I suppose the link I seem to be missing is why a subroutine call would not be satisfactory for this.
Granted, each child may not know who its parents parent is, okay, but heres where object states fit in, if this makes any sense... $Object->parent() reports the objects parent, obviously you can use this as a singly linked list to find not only the parent but the parent's parent's parent's....you get the idea, all the way until the root object.
my $root = $self->parent;
while ($root->parent) { $root = $root->parent }Below is the spawn/trace mechanism... Obviously you'd want to throw some error checking and things in, but I'm putting my faith in the programmer for sake of shorter example code.
package My::Object;
sub states {
return [ qw( _start have_a_kid _stop ) ];
}sub _start {
... do my POE stuff ...
}sub have_a_kid {
POE::Session::Maker->spawn(shift, "My::Kids::Package");
}sub parent { shift->{-parent} }
sub new {
bless { -parent => pop }, shift;
}package My::Session::Maker;
sub spawn {
my ($this, $parent, $package);
my $object = $package->new($parent);
POE::Session->create(object_states => [ $object => $object->states ]);
}__END__
but then again
I'm not even sure I really understand what you're saying.
- Scott
