Front page | perl.perl5.porters |
Postings from January 2012
> That's a bit another problem. > Let's look: I'm a user of AE and IO::Async. I don't know about possible > problems when I will use them together. > So, from point of user I rather say thanks to Marc for warning me (maybe in > a too strict way: warn would be enough), than to Paul for anyevent brokage > (possible) without warning. From the point of view of somebody who -was- an active production user of both, this isn't what happened. In fact, IO::Async::Loop::AnyEvent was written to -avoid- problems. I had a significant sized AnyEvent application. Since it was already running reliably on its existing Impl, I did not want to have to switch it to using AnyEvent::Impl::IOAsync (which still works imperfectly, but I don't have good repro cases for the problems I encountered and now never will, for reasons to be explained). Thus, in order to use an IO::Async component within this process, I was able to load IO::Async::Loop::AnyEvent, thereby localising any problems to the new code, and allowing me to deploy the results to production with confidence. Then an AnyEvent upgrade killed it. My client's answer to this was to ban all future use of AnyEvent within their codebase and to authorise a rewrite of the relevant daemon to a pure IO::Async system, since they were unwilling to risk that they would again suffer from a situation where Marc intentionally destroyed perfectly working production code over a personal philosophical difference. As such, I'm unlikely to ever find out why Impl::IOAsync doesn't work for that code and I am, on the whole, comfortable with this fact. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.