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

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"..

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

    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]
      > If you have a (simple) testcase that demonstrates the 
> problem I'd be happy to take a look at it.

      [download]

      Here is a simple POE::Component:IKC implementation. You'll have to run both with different processes. Uncommenting the server's async call throws an exception on win32 with ActiveState Perl. Any ideas how to make POE really thread-safe?

      Kind regards.

      Michael.

      For the sample code,
      Read more... (6 kB)
[reply]
[d/l]
[select]
        Any ideas how to make POE really thread-safe?

        No. That's waaay beyond my ambitions. If the POE guys, that includes the author of ithreads, can't achieve that, I wouldn't know where to begin.

        But it may be possible to use threads in such a way that they don't interfere with POE.

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

In Section Seekers of Perl Wisdom