Bug #50907 blocks ActiveState auto-packaging of POE since May
Could someone have a look at bug #50907 ? t/30_loops/select/connect_errors.t failure on Win32 (blocks ActiveState PPM auto-packaging) http://rt.cpan.org/Public/Bug/Display.html?id=50907
Re: Bug #50907 blocks ActiveState auto-packaging of POE since May
Hmmm... I thought I had a ticket for the connect_errors failure, but I don't see it now. Maybe I just talked about it on IRC. I haven't played with this for a few weeks, but as I recall Windows is simply refusing to timeout the connection. If connect_errors.t is modified to use the ConnectTimeout option to POE::Component::Client::TCP then everything works just fine. -Andrew Olivier Mengué wrote: Could someone have a look at bug #50907 ? t/30_loops/select/connect_errors.t failure on Win32 (blocks ActiveState PPM auto-packaging) http://rt.cpan.org/Public/Bug/Display.html?id=50907
Debugging not stopping sessions
Hi, I'm using POE::Wheel::Run::Win32 0.16 with POE 1.006 on ActivePerl 5.10 (1003). My POE-based program has a main session which launchs sessions which use a P::W::R::Win32 to run an external process. The process are running OK, the output is returned OK, the sig_child is fired as expected. Also, the wheel is released and destroyed. But the problem I have is that the session around the wheel is never released. This is a problem because I don't want to stop my main session before all child programs are stopped. So I wonder what is keeping the session alive. I've not been able to reproduce the problem with a simple test case The ASSERT flags I tried are unusable due to the amount of data they print. I tried to track the session refcount, but it seems to be quite low. So here is my question: what can I use to track what is keeping the session alive ? How can I inspect the session (even using private APIs) and the kernel ? Olivier.
Re: Debugging not stopping sessions
Hi, Olivier Mengué schrieb: So here is my question: what can I use to track what is keeping the session alive ? How can I inspect the session (even using private APIs) and the kernel ? Adding following line to the top of your code, before you create the session will output additional kernel debug messages. sub POE::Kernel::TRACE_REFCNT() { 1 } I did not figure out though how to see what actually keeps the kernel/session alive. I only can figure out now that something is keeping it alive. More information on this topic would be appriciated. Regards, Andreas signature.asc Description: OpenPGP digital signature