tag:blogger.com,1999:blog-9112560338291574360.post8576312811901260743..comments2024-03-02T08:28:27.119+00:00Comments on LeoNerd's programming thoughts: Perl - IO::Async - version 0.34LeoNerdhttp://www.blogger.com/profile/06161372680495361467noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-9112560338291574360.post-37345331912179491862011-01-01T17:15:50.444+00:002011-01-01T17:15:50.444+00:00The functions themselves probably do block yes, if...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.LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-63601209151093184352011-01-01T08:51:23.288+00:002011-01-01T08:51:23.288+00:00Thanks, Paul.
Didn't knew about the getaddrin...Thanks, Paul.<br /><br />Didn't knew about the getaddrinfo(3)/getnameinfo(3) part. I assume that the trade-off is that those functions block.<br /><br />And I see that yesterday Marc released the new AnyEvent with your changes, cool.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-18795300447989563482010-12-31T12:04:16.767+00:002010-12-31T12:04:16.767+00:00At Tom points out, AnyEvent is a wrapper layer -ab...At Tom points out, AnyEvent is a wrapper layer -above- the actual event systems. IO::Async is one such system, POE is another.<br /><br />Recently, 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.<br /><br />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...LeoNerdhttps://www.blogger.com/profile/06161372680495361467noreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-78278060929781540902010-12-31T09:39:28.847+00:002010-12-31T09:39:28.847+00:00As I understand it, AnyEvent is a layer on top of ...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.<br /><br />Not 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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9112560338291574360.post-70481230409511373292010-12-30T20:49:55.380+00:002010-12-30T20:49:55.380+00:00Hi Paul,
nice new features. Could you explain whe...Hi Paul,<br /><br />nice new features. Could you explain when should we use IO::Async or AnyEvent?<br /><br />Any strong points of IO::Async over AE you want to point out?<br /><br />Thanks,Anonymousnoreply@blogger.com