Skip Menu |
 

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 19386
Status: rejected
Priority: 0/
Queue: POE

People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Perl 5.8.0: POE becomes unresponsive with only signals and selects
Download (untitled) / with headers
text/plain 829b
For some reason, I'm seeing POE go into an unresponsive state when it has signals live (INT and TERM in my case) and selects (in this case a Wheel::ReadWrite wrapping a serial port. If there are other things like timers (Most of the time I have some keepalive timers) around, the signals and such seem to be responsive, but POE goes into a dead state and becomes unresponsive if it's ONLY the signals and serial port. Would it be possible to write some form of test script which tests this case (the unresponsive to signals case). For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, it would be very useful to be able to create a test that fails, so 5.8.0 can be ruled out as a bad platform. It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would be better if we could test for the case.
Download (untitled) / with headers
text/plain 1.4k
On Sun May 21 10:24:48 2006, guest wrote: Show quoted text
> For some reason, I'm seeing POE go into an unresponsive state when it > has signals live (INT and TERM in my case) and selects (in this case a > Wheel::ReadWrite wrapping a serial port. > > If there are other things like timers (Most of the time I have some > keepalive timers) around, the signals and such seem to be responsive, > but POE goes into a dead state and becomes unresponsive if it's ONLY the > signals and serial port. > > Would it be possible to write some form of test script which tests this > case (the unresponsive to signals case). > > For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, > it would be very useful to be able to create a test that fails, so 5.8.0 > can be ruled out as a bad platform. > > It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would > be better if we could test for the case.
You're the person most likely to tell us whether a test case is possible. You have the system that's failing, and the code that fails. I could take a stab at writing a test case, but I have no frame of reference from which to start, so it's probably just a waste of time. How we react to the test case depends on where the fault lies. If it's in Perl, we'll have something that demonstrates empirically that 5.8.0 is considered harmful. If it's in POE, we should try to work around the issue as best as possible. That may mean throwing runtime errors when certain features are used on 5.8.0.
Subject: Re: [rt.cpan.org #19386] Perl 5.8.0: POE becomes unresponsive with only signals and selects
Date: Mon, 22 May 2006 12:12:54 +1000
To: bug-POE [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Download (untitled) / with headers
text/plain 1.9k
Indeed. But I'm wondering where to start... there's some basics I might be able to try, but it could take quite a lot of time to find it, so I'm wondering if you know to what level of depth things like signals or idleness, or whatever, are tested. It's hard to decode the test scripts, they mostly seem to test internals and don't actually test whether the various sigs work... I think... Adam K via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=19386 > > > On Sun May 21 10:24:48 2006, guest wrote:
>> For some reason, I'm seeing POE go into an unresponsive state when it >> has signals live (INT and TERM in my case) and selects (in this case a >> Wheel::ReadWrite wrapping a serial port. >> >> If there are other things like timers (Most of the time I have some >> keepalive timers) around, the signals and such seem to be responsive, >> but POE goes into a dead state and becomes unresponsive if it's ONLY the >> signals and serial port. >> >> Would it be possible to write some form of test script which tests this >> case (the unresponsive to signals case). >> >> For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, >> it would be very useful to be able to create a test that fails, so 5.8.0 >> can be ruled out as a bad platform. >> >> It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would >> be better if we could test for the case.
> > You're the person most likely to tell us whether a test case is > possible. You have the system that's failing, and the code that fails. > I could take a stab at writing a test case, but I have no frame of > reference from which to start, so it's probably just a waste of time. > > How we react to the test case depends on where the fault lies. If it's > in Perl, we'll have something that demonstrates empirically that 5.8.0 > is considered harmful. > > If it's in POE, we should try to work around the issue as best as > possible. That may mean throwing runtime errors when certain features > are used on 5.8.0.
Fair enough. A start would be to turn on TRACE_DEFAULT and redirect the copious amount of debugging information to a file. Stop the program after it has reached the unresponsive state, and then isolate the state change in the log. Attach maybe 50KB of log leading up to the point where the program became unresponsive, and a few iterations of the main loop afterwards. That might show the cause of the state change, and it'll let me know the execution pattern afterwards. I probably can't solve the issue directly from that, but I may be able to direct you to look at specific things. On Sun May 21 22:09:05 2006, adam@phase-n.com wrote: Show quoted text
> Indeed. > > But I'm wondering where to start... there's some basics I might be able > to try, but it could take quite a lot of time to find it, so I'm > wondering if you know to what level of depth things like signals or > idleness, or whatever, are tested. > > It's hard to decode the test scripts, they mostly seem to test internals > and don't actually test whether the various sigs work... I think...
Download (untitled) / with headers
text/plain 126b
No testcase or feedback from requester. Can't reproduce the problem or fix it. Perl 5.8.0 sucks anyway. Ticket is rejected.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.