clean. Bump the version to 0.22 for release.
for pointing it out.
adding one, I realized that STDIN, STDOUT *and* STDERR were all sharing a single internal driver instance. That's bad because three handles cannot reliably share a single driver (which can only read on one handle and write on one handle reliably). This may have uncovered a nasty bug in Wheel::Run. Thankfully, 0.22 has not yet been released.
BlockSize documentation so that it does not apply to syswrite().
case, it was IO::Select. Now I've discovered that IO::Poll is slow as well. This is the price one pays for using generic modules, however. I researched IO::Poll and discovered its internal _poll function, which is written in XS. POE::Kernel::Poll was revised to use that directly rather than incurring overhead from using the public interface. I only hope I can keep up with IO::Poll changes. POE::Kernel::Poll should really be better than select() now regarding latency and scalability, if only a little bit.
(zombie) processes. I suspected that it was a race between program shutdown and POE::Kernel's reaper. Matt was able to verify this by adding some non-blocking reaper code after run() was called. I added code to POE::Kernel that keeps it alive as long as there are outstanding child processes. This will ensure that they're reaped (no more defunct zombies).
Baud? Kane?) pointed out a typo. Thanks, whoever you are.
reporting the leak (usenet message-ID:3D16D3B2.11FC919E@tellabs.com) and Slaven Rezic (usenet message-ID:firstname.lastname@example.org) for the way to avoid it.
from the deprecated Filter parameter.
single Filter instance cannot possibly filter three filehandles! The fix was to replace Filter with StdioFilter, which only filters STDIN and STDOUT. StderrFilter must be specified separately. It's easy to write code that is compatible with the old and new interfaces (for a module, for example). Just use StdinFilter, StdoutFilter, and StderrFilter explicitly.
changes address some of the the issues he discovered. They mainly fall under the categories of signals, UNIX sockets, socketpair(), and fork() incompatibilities between UNIX systems and MacOS pre-X.
First, it's possible to run the IO::Poll tests with an older version by saying "no" to installing a newer one. That leads to test failures later on. The work-around is to add checks in POE::Kernel::Poll and t/27_poll.t for the proper IO::Poll version. Second, he pointed out that a few dependencies were missing from the installer. Added!
improved Perl build, these systems seem to have strange problems with non-blocking socketpair() and pipe().
Client::TCP respectively. They were recently "enhanced" to accept filter instances, and they would create filter instances from class names internally. However, this new "feature" meant that every connection SHARED THE SAME FILTER. The changes now let them accept class names and optional constructor parameters, and the components will instantiate new filters for each connection. "MarkClone" on efnet reported that the POE Cookbook web server was only honoring its first request; the remainders were bombing out with an error which led me to this problem.
in response to Jos Boumans' question about it.
things line up.
to Zoltan Kandi for making sure it works.
POE::Filter::Reference's dependencies. Now it does. :)
about that. Now it's all better.
back to not calling $poe_kernel->run(). This happens to me ALL THE TIME, and feelicks (and I) is sure it happens to a lot of people. I added a flag that's set when run() is called. POE::Kernel's DESTROY will warn the programmer/operator if that flag is not set.
tarballs. The order of operations in "make dist" means that PREOP occurs AFTER CHANGES is copied into the tarball tree. D'oh!
it. Even though we generate CHANGES from the CVS log, WriteMakeFile needs to see something there first.
operator. I put quotes around it, and things seem to be generally better.
POE::Kernel::Tk's file watcher pause/resume code. I adapted a previous plain-Tk testcase to verify the behavior outside POE. It's there in Tk on Perl 5.004_05. The testcase doesn't fail with Perl 5.005_03, so it looks like an incompatibility between Tk and the older version of Perl. I've decided to discontinue Tk support in Perl versions before 5.005_03. If anyone has a vested interest in the older Perls + Tk + POE, I can provide the test case for their debugging pleasure.
what I get for testing stuff on systems that have everything.
POE's CHANGES automatically from the cvs log. No more twiddling with it by hand! Yay! P.S., Everybody better commit decent change descriptions, or else.