Home > Archive > PERL POE > June 2007 > STDOUT, POE::Filter::Reference and other people's code
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
STDOUT, POE::Filter::Reference and other people's code
|
|
| Zach Roberts 2007-05-31, 10:22 pm |
| Hello POE,
I have a situation which I am sure is not unique, but I haven't been
able to find much information about it. I am using POE to provide a
parent process which spawns many children (via POE::Wheel::Run) who do
their various things (in my case some memory heavy conversion and
manipulation of database records). This is working beautifully and
has made my life very simple and happy.
There is one nuisance that I haven't been able to figure out though,
and I am hoping that someone can help. I am using
POE::Filter::Reference to handle the the child to parent communication
of the results from each child process. I am currently using a
POE::Filter::Reference as the StdoutFilter parameter to my
POE::Wheel::Run, similar to the examples in the POE Cookbook (see
http://poe.perl.org/?POE_Cookbook/Child_Processes_3). This works
really, really well for cases where all of the code knows that it is
POE code, and that anything the child process writes to STDOUT is
going back to the parent process through the filter. What should I do
though for the cases where the child process (or more likely one of
the modules it uses) may have no idea that it is POE code and that
STDOUT should be reserved for communication back to the parent? One
case, as an example, is when a --verbose flag is passed to the child
process resulting in all kinds of chatter on STDOUT that the filter is
not good at ignoring as non POE communication. Is there some
filehandle trickery that can be done to convince all the non-POE
STDOUT printing to go elsewhere, like STDERR, and then only the POE
specific printing can monopolize STDOUT for filter printing only? Is
there a way of chaining filters together to ignore non POE
communication on STDOUT? Any other ideas (short of the obvious make
all the other code running in the child behave the way I want it to)?
If this is unclear, feel free to say so and I will work on a self
contained program to post as an example. Thanks again,
Zach Roberts
| |
| Nicholas Perez 2007-06-01, 7:21 pm |
| You could make use of Filter::Stackable to put in a "sieve" filter in
front of Filter::Reference. Your sieve could then check to make sure
(read: hand waving) the data it gets from whatever is valid for
Filter::Reference. If it isn't just eat it. Depending on what
Filter::Reference uses for serialization (Storable? YAML?) you can do
a check on the first few bytes to see if it is valid.
I don't have an example off the top of my head to show you or further
explain the concept, but I do know that in the .NET remoting
architecture, their Sink concept loosely follows the Filter::Stackable
concept. And there are a bit more hits on google for custom remoting
sinks (to do things like trap errors before they get too far up the
chain).
HTH
On 5/31/07, Zach Roberts <tozachroberts@gmail.com> wrote:
> Hello POE,
>
> I have a situation which I am sure is not unique, but I haven't been
> able to find much information about it. I am using POE to provide a
> parent process which spawns many children (via POE::Wheel::Run) who do
> their various things (in my case some memory heavy conversion and
> manipulation of database records). This is working beautifully and
> has made my life very simple and happy.
>
> There is one nuisance that I haven't been able to figure out though,
> and I am hoping that someone can help. I am using
> POE::Filter::Reference to handle the the child to parent communication
> of the results from each child process. I am currently using a
> POE::Filter::Reference as the StdoutFilter parameter to my
> POE::Wheel::Run, similar to the examples in the POE Cookbook (see
> http://poe.perl.org/?POE_Cookbook/Child_Processes_3). This works
> really, really well for cases where all of the code knows that it is
> POE code, and that anything the child process writes to STDOUT is
> going back to the parent process through the filter. What should I do
> though for the cases where the child process (or more likely one of
> the modules it uses) may have no idea that it is POE code and that
> STDOUT should be reserved for communication back to the parent? One
> case, as an example, is when a --verbose flag is passed to the child
> process resulting in all kinds of chatter on STDOUT that the filter is
> not good at ignoring as non POE communication. Is there some
> filehandle trickery that can be done to convince all the non-POE
> STDOUT printing to go elsewhere, like STDERR, and then only the POE
> specific printing can monopolize STDOUT for filter printing only? Is
> there a way of chaining filters together to ignore non POE
> communication on STDOUT? Any other ideas (short of the obvious make
> all the other code running in the child behave the way I want it to)?
>
> If this is unclear, feel free to say so and I will work on a self
> contained program to post as an example. Thanks again,
>
> Zach Roberts
>
| |
|
|
|
|
|
|
|
|
|
|
|