in reply to Re^3: POE and Win32::Process control
in thread POE and Win32::Process control

> That's a complex entity

[download]

I agree

> some ambiguities in your description.
  (...)
> What if a read request is received for 
> a process that has already started and 
> produced half it's output?

[download]

Of cause, the user/ node who attached to a process which has not terminated, yet, after the process has already produced some output, the user first received the old output and next recieves the on-going output as it is produced by the continuing process.

Thank you very much for your Thread example. I am excited about its cooperation with POE on win32.

Replies are listed 'Best First'.
Re^5: POE and Win32::Process control
by BrowserUk (Patriarch) on Feb 13, 2005 at 22:14 UTC

    Two clarifications just in case:

    Thank you very much for your Thread example
  • Please note: The example uses threads not Thread!

    They are different and incompatible modules. The former requires 5.8.x, preferably 5.8.4 or later.

    The latter was for versions earlier that 5.8.0, is deprecated, and will cease to function in 5.10.x.

    I am excited about its cooperation with POE on win32.

    Note: I said that I am not sure whether threads and POE will work together, they may not. I am not sure if anyone has tried this combination.

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
[reply]
      I tried POE and threads. Even though they say something about it (http://poe.perl.org/?Poe_faq/is_poe_thread_safe) I have the impression, that POE is not thread-safe. win32 complains with an Attempt to free unreferenced scalar: SV 0x2afba80 during global destruction when I create a thread inside a session. The process continues. If it comes to a point, where this execution has to be triggered again, Perl aborts with an Application Error dialog - The instruction at bla bla referenced memory at bla bla. The memory could not be "read"..
[reply]

        The reference you give, in particular:

        POE is very flexible, however. It may be possible to spawn threads for dedicated tasks, and pass information back and forth using Thread::Queue. To our knowledge, nobody has done this yet.

        was the basis of my speculation that it might be workable.

        If anyone can make them co-exist Sky is your guy.

        The "Attempt to free..." error is probably not a big problem. Effectively that's just an attempt to free something twice, was recognised and noted. It shouldn't cause a problem beyond the disconserting message.

        It is harder to assess whether segfault is a result of a total incompatibility, or whether discovering the right set of incantations would alleviate the problem. If you have a (simple) testcase that demonstrates the problem I'd be happy to take a look at it.

        I've done very little with POE but as I understand it, you should be able to spawn the child process using the same "piped-open" as I showed in the threads example and give the handle from the open to POE to manage for you. Basically, you would simply be adding another handle to the list of handles that POE is already performing the select or IO::Select management of.

        How you would go about giving the handle to POE, I don't know, but it should be possible.

        That's probably my biggest problem with POE (and several other "framework modules"). If they have a widget or wheel that does what you need it to, and that widget or wheel compiles for your system, then you are laughing.

        But if you need to do something slightly different, you are so far removed from the basic underlying functionality, you're kinda stuffed.

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
[reply]

In Section Seekers of Perl Wisdom