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. Thanks, Tim On Fri, Nov 30, 2018 at 10:53 AM Marc Lehmann <[email protected]> wrote: > On Thu, Nov 29, 2018 at 02:57:29PM -0800, Tim Na <[email protected]> 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 > MORPG > -----==- _GNU_ http://www.deliantra.net > ----==-- _ generation > ---==---(_)__ __ ____ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ >
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
