That's interesting. I tried to read up POE couple of times, but found the learning curve to be steep :-(
Can POE pre-empt a session ? I thought something like yield()
has to be called from the code block for the POE kernel
to look at events. If a code blocks for quite sometime, then
POE kernel wouldn't be aware about other session events - am I right ? Or am I talking non-sense ? :-)
Also, wouldn't I need to change my entire existing codebase to make it POE enabled ? I have a new module that spawns and controls processes, where I can use POE. I do not know how much of work it'd involve to use POE for the rest of the code.
thanks ! | [reply] |
If you use POE::Wheel::Run then you can run a sub in a separate forked process. That sub could run your existing f2() and then print something to STDOUT (say f2 done). The parent session in the parent process has something watching for output from that child wheel which sends itself a "f2done" event (and upon receiving that event it starts whatever was waiting for f2 to complete). It wouldn't be seamless, but it should be doable.
--
We're looking for people in ATL
| [reply] [d/l] [select] |
My existing routine prints everything to it's stdout, which is redirected to a log file before fork(). But I think I can use a different filehandle for communication. I'll dig up the doc. to see what POE does if a session blocks forever or a child exits abruptly. I think it'd also mean the application cannot use CHLD handlers, as it'd interfere with POE's.
| [reply] |