question on using INADDR_LOOPBACK in ev_pipe

Tim Na timna2 at
Fri Nov 30 20:37:16 CET 2018

okay - thanks for your response.

So far I have asked our customers to lower restriction or make exception to
our app solely because of this issue of using local loop ip.  It worked
well until we are getting a lot more customers to handle and most of them
(95%) are windows users.  These majority users in enterprise world with IT
folks who are paranoid about security to install top security anti-virus to
its highest restriction don't get these things and they are simply annoyed
when things doesn't work.

I know the work involved to migrate from libevent to libuv wouldn't be easy
as I looked thru the APIs but I guess I will have to bite the bullet and
find some workaround somehow.


On Fri, Nov 30, 2018 at 10:53 AM Marc Lehmann <schmorp at> wrote:

> On Thu, Nov 29, 2018 at 02:57:29PM -0800, Tim Na <timna2 at> wrote:
> > Sorry about that silly mistake (or threats) - I just learned not to use
> > company's email system for such request now.  Sincere apologies for such
> > annoyance to you and libev community.
> >
> > However, I question still stands and I am looking at libuv as alternative
> > choice as it seems to have no such limitation as libevent or libev.
> There is no limitation in libevent or libev, what you describe is a bug or
> misconfiguration of other components on your system (basically, you are
> saying that using TCP/IP is a limitation in libev, this is silly). If you
> disable your broken virus scanner of whatever causes the problems things
> start to work (this also affects firefox and many other programs which
> are forced to poll if they can't get a local socket to work, i.e. they
> might superficially work, but only because they run a 100Hz timer in the
> background and poll for events).
> Another option would be to switch to an OS such as GNU/Linux, which
> doesn't have the limitations of the windows platform (you haven't
> mentioned what platform you are using, but it sure sounds like windows) -
> both in terms of broken virus scanners/firewalls breaking the TCP/IP stack
> and in lacking efficient local sockets.
> You could also try libuv, although my personal totally unbiased opinion is
> that libuv suffers from many design bugs that more mature libraries such
> as libev (or libevent) do not suffer from because libuv was designed by
> people unknowledgable in event systems and therefore were bound to repeat
> many mistakes of earlier ad-hoc event libraries.
> Of course, if you don't care about correctness and just want to make
> things superficially working, then you could call it a limitation in
> libevent/libev and use libuv, if that works for you (and unknowingly
> suffer later because you run into design issues you wouldn't notice with
> better event libraries).
> A real reason to switch to libuv is performance - libev doesn't do I/O for
> you, and this tends to make it slow on windows, which doesn't support I/O
> readyness notifications efficiently. libuv _does_ do I/O for you and might
> be more performant if all you can use is windows. OTOH, if all you can use
> is windows, you clearly don't care about performance much, so why bother
> :)
> Using libuv in this way will also require to rewrite any existing
> event-based code to be I/O-based instead which might or might not be an
> issue.
> --
>                 The choice of a       Deliantra, the free code+content
>       -----==-     _GNU_    
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at
>       -=====/_/_//_/\_,_/ /_/\_\
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the libev mailing list