- New Notifier class IO::Async::Timer::Absolute, to invoke events at a fixed point in the future.
- New Notifier class IO::Async::PID, to watch a child process for exit(2).
- New Notifier class IO::Async::Protocol::LineStream, to implement stream protocols that use lines of plain text.
- New method on IO::Async::Protocol that wraps connect(2) functionallity, allowing for simpler network protocol client modules.
- IO::Async::Loop->connect's on_connect_error and IO::Async::Loop->listen's on_listen_error continuations now both receive errno information.
- New direct name resolution methods on IO::Async::Resolver for getaddrinfo(3) and getnameinfo(3). The resolver is now directly accessible from the IO::Async::Loop.
- IO::Async::Resolver supports deadline timeouts.
- IO::Async::Stream->write supports taking a CODE reference to dynamically generate data for the stream on-demand.
- IO::Async::Stream->write supports an on_flush callback.
- The IO::Async::Loop->new magic constructor now caches the loop. This is useful for wrapping modules, other event system integration, etc..
- Documentation has been rearranged to add new EVENTS sections, documenting the events that Notifier classes can fire either as callbacks in coderefs, or as methods on subclasses.
- Various bugfixes, other documentation additions
2010/12/30
Perl - IO::Async - version 0.34
There's been four releases of IO::Async since I last wrote about version 0.30. Here's a rough summary of the more important changes and additions between then and version 0.34:
Subscribe to:
Post Comments (Atom)
Hi Paul,
ReplyDeletenice new features. Could you explain when should we use IO::Async or AnyEvent?
Any strong points of IO::Async over AE you want to point out?
Thanks,
As I understand it, AnyEvent is a layer on top of existing event libraries such as IO::Async or POE, so it's not really a question of either/or - there are some modules for AnyEvent that aren't yet available directly for IO::Async, but you should be able to mix those with existing IO::Async code without problems.
ReplyDeleteNot sure whether AnyEvent has been keeping pace with recent IO::Async development, but note that there's also been some work recently to allow IO::Async to use other event loops (even having IO::Async::Loop on top of an existing IO::Async::Loop), so perhaps it's not too farfetched to mix IO::Async, AnyEvent, POE and GLib code in the same project.
At Tom points out, AnyEvent is a wrapper layer -above- the actual event systems. IO::Async is one such system, POE is another.
ReplyDeleteRecently, I got IO::Async::Loop::POE working, so you can happily mix IO::Async + POE code together. Also I fixed AnyEvent::Impl::IOAsync, so hopefully the next version of AnyEvent will run nicely on top of IO::Async.
As to particular strong points, I'm not sure I'm familiar enough with AnyEvent to make much of a comment there. But one thing that does come to mind is that IO::Async is, as far as I know, the only Perl event loop system that actually uses the real system name resolver functions getaddrinfo(3) and getnameinfo(3). All the others contain their own custom DNS implementation. The upshot here being that IO::Async will resolve names exactly as the rest of the system, obeying nsswitch.conf, /etc/hosts, and so on, whereas the others will invariably differ in some way. It's a topic I may write another post about at some point...
Thanks, Paul.
ReplyDeleteDidn't knew about the getaddrinfo(3)/getnameinfo(3) part. I assume that the trade-off is that those functions block.
And I see that yesterday Marc released the new AnyEvent with your changes, cool.
The functions themselves probably do block yes, if they have to make DNS, LDAP, SQL, or other queries. That's why IO::Async::Resolver wraps them away in an IO::Async::DetachedCode object, which runs them in a separate process, ensuring it doesn't block the main program.
ReplyDelete