> Ofer Nave wrote:
> > That's great news!
> >
> > Do you have an ETA, Michael?
> >
> > -ofer
> >
> > Rocco Caputo wrote:
> >
> >> On Thu, Oct 21, 2004 at 10:12:20PM -0700, Michael Nino wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> Okay, POE is a multitasking environment but how? I'm new to POE and
> >>> want very much to use it but cannot figure out how. It must be so
> >>> simple I cannot see how to implement it. In short, I have a name
> >>> server zone file that I want to process. I want an arbitrary number
> >>> or workers processing the file. I am currently using
> >>> Parallel::ForkControl successfully but I want to use POE. Here is my
> >>> current code. Thank you sooooooo much in advance!
> >>>
> >>> Sincerely,
> >>> Michael
> >>>
> >>
> >>
> >> I don't understand why you would want to change a tidy little program
> >> that already works well.
> >>
> >> The POE version would only be as tidy as your existing code if someone
> >> writes a component as specialized as Parallel::ForkControl. That
> >> person would probably be someone who needs the code (or who is paid to
> >> write it). So far you are the most likely candidate. :)
> >>
> >>
> >>
> >
>
> LOL. You guys I am probably not explaining myself very well or I am
> misunderstanding. First, I would very much like to participate in the
> POE project but my question was this:
>
> Doesn't POE::Wheel::Run offer the same basically functionality as
> Parallel::ForControl. If so, how would one implement a basic
> multiprocess script.
>
> Thanks,
> Michael
>
>
POE::Wheel::Run provides the basic component of IPC needed to write
something similar. How you implement it really depends on what your
goals are. Our application, written using POE, uses a series of
processing queues to control varying numbers of simultaneous executions
in multiple stages of an overall process. For instance, we use a
pre-processing stage, an encryption stage, a transfer stage, and a post
processing stage. Each has varying levels of impact on the machine, for
instance encryption is CPU intensive but relatively fast, OTOH the
transfer stage is low CPU, but is blocking so is usually slow. It is
also possible for a single part of the process to fail, immmediately
dropping to post processing, or in some cases the encryption is skipped
completely. We use a directory polling component, any I/O component
would do, to trigger a process being placed in the first queue. The
queues are implemented as objects that wrap a POE session, which allows
us to notify the queues, and to prevent the need for a constant cycle
(aka the queue only pops a new element to process when a new element is
added or one finishes), also allows us to control the number of
concurrent processes, etc. We have considered adding prioritization,
etc. but haven't gotten around to it.
Sample code, untested, and stripped down can be viewed for the time
being here:
http://danconia.org/perl/POE/ProcessQueue.pm
Most of what I learned I got from the Cookbook as another poster stated,
specifically the Child Process and Application Server sections. I would
highly suggest using the object state sessions instead of inline, but
that's just my personal thoughts.
Good luck,
http://danconia.org
|
