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.