Re: catching exceptions in sessions
Sungo wrote: hell, i'm still waiting for the COMMENTS, let alone a pattern to emerge from them. the module seemed to kill the conversation and i've never figured out whether that meant that i hit a home run or totally scared everyone off :) I have some observations about the module. Please correct me if I'm wrong or if I've misunderstood anything about the design of the module. I like the idea of POE::Exceptions, but I feel it doesn't accurately represent the way exceptions should be used. I think one of the biggest problems is the fact that it uses a POE DIE signal to indicate an exception has occured. I feel like this encourages programs to be written that have a single exception session that handles exceptions for the entire program. This is probably okay for small programs. However, I'm not sure how easy it would be once you start adding components in the mix that throw and/or catch exceptions. It seems to me in this case there would be a good chance that the wrong session might catch another sessions exception. In general, it would seem to negate the modularity of components. I think what we need is a way to KNOW where the exception is going to go. With non-POE exceptions, when you throw an exception, you know where the code is going to go (outside the eval in perl or in the catch block in some other language). With the current module, one doesn't neccessarily know who's going to catch the exception. Maybe we need the kernel sending a predefined event to the parent of the session that throws the exception (to represent a catch block in the calling code)...I don't know. Of course, another problem is that we can't rethrow exceptions. I think this is an important concept in non-POE code. -- LG
Re: 0.3003+cygwin+perl 5.8.5
Rocco Caputo wrote:
In that case, try changing the test in nonblocking() so it falls
through to the POSIX code on Cygwin?
...
unless ($^O eq MSWin32) {
if ($] = 5.008 and $^O ne Cygwin) {
$handle-blocking(0);
}
else {
# Long, drawn out, POSIX way.
...
I can commit that for the next release if it works.
Unfortunately, this makes no difference. I made sure that the alternate
code was executed. It locks in exactly the same way, on test 12 while
performing a syswrite. I wanted to point out a couple of different things:
If I change line 96 in the following way:
my ($r, $w) = POE::Pipe::OneWay-new(inet);
or
my ($r, $w) = POE::Pipe::OneWay-new(socketpair);
the tests passes test 12 and 13, but locks up while trying to close, on
line 124: close($w).
Unfortunately, I haven't had any time to do any deeper troubleshooting
than that. I'm still curious if there are any other cygwin users out
there that have had success with this version of POE.
--
Leif Gustafson
Re: 0.3003+cygwin+perl 5.8.5
Rocco Caputo wrote: The problem is probably in the test program itself. I've had problems with this test on different systems. I haven't noticed this test failing on previous versions of POE, but maybe it's a new test, I haven't checked. The idea is to set the pipe non-blocking, and use Driver::SysRW to flush as much data to the pipe as it will hold. Eventually the pipe fills up, and the driver's can't write anymore code is exercised. It sounds like the pipe isn't really non-blocking, despite the nonblocking() code in 01_drivers.t. One thing to try is replacing nonblocking() with $w-blocking(0). You may need to use IO::Handle first. The intersting thing is that I followed the code through nonblocking() in the test. In that function, $handle-blocking(0) is definitely called, as $^0 neq MSWin32 on cygwin. Maybe it doesn't work properly though on cygwin.I'll try and look at this further at a later time. -- Leif Gustafson
0.3003+cygwin+perl 5.8.5
I have a problem with the tests on POE 0.3003 on cygwin running Windows XP with perl 5.8.5. I don't believe it is a POE bug, but I am curious if any other cygwin users have experienced it. Test 11 of 17 in 10_units/04_drivers/01_sysrw.t locks up perl. I have traced the problem through to POE::Drivers::SysRW, in the flush method. Running through the perl debugger, I have discovered that perl locks on the third call to syswrite in the loop. Looking at the CVS diff of SysRW.pm, the only thing that has been added in that method since that last stable release of POE was line 140: $! = 0 if defined $wrote_count; but I don't think this has anything to do with the problem, so I feel the problem is elsewhere. Anyhow, since syswrite is hanging, my feeling is that this is a cygwin bug, or a cygwin perl bug. Has anyone else had success with cygwin. If so, please post what version of the cygwin dlls you are using and what version of perl. -- Leif Gustafson
Re: POE and exceptions
Sungo wrote: not so much. i imagine we'd probably add a _death handler or something. and if no one registered that they care about exceptions, we'd just let the die pass on through like normal and terminate the program -- sungo http://eekeek.org That's a good way of handling it. Are there any solid plans for implementing this? Is there anything currently holding this back technically (obviously other than no one has had time or desire to make and test patches)?
POE and exceptions
Hi, I am curious how other users handle exceptions with POE. I have explored POE::Exceptions to some degree, but unfortunately it requires a degree of cooperation between all the components, and I don't know of any other components that use POE::Session::Exception. Are there any plans to build exception handling into the base distribution of POE?
Re: POE and exceptions
Sungo wrote: POE::Exceptions was an idea we had for how to put exceptions in the core. the hope was to spur discussion and other ideas beyond my implementation thoughts. turns out that was false hope. *shrug* -- sungo http://eekeek.org Well, I certainly like the idea of sending a die signal. It actually gives you more control over your exception handlers than what can be easily done in non-POE programming. For example, you could have a single exception-handling session, or have a session handle it's own exceptions. The trickiest part, I think, is actually having the parent session handle the child sessions exceptions. It seems like parent session has to keep an updated list of child sessions through the _child state and compare every die signal against it. Anyway, wish it was in the core.but I imagine it might break some programs out there if die suddenly stops killing programs and starts throwing exceptions.
