Martin> Just thinks that getaddrinfo is not thread-safe on OSX, so it
Martin> needs to use a lock around getaddrinfo.
I've been thusfar unable to get the code in getaddrinfo.c to compile as part
of socketmodule.c (errors about missing #defines and struct members).
Unless maybe Barry or Jack can figure out what the problem is, I think
solving this particular performance problem may have to wait until after the
2.3 release.
Martin> It is surprising that this has caused a slow-down, in particular
Martin> on a non-threaded application. If there was a bug in this code,
Martin> I had expected that to cause a deadlock, instead of causing a
Martin> slow-down.
It looks like the Mac OS X implementation of getaddrinfo is just dog slow.
I instrumented setipaddr with calls to gettimeofday() to see how long
different sections took. It turns out that getaddrinfo() is hideously slow:
start: 5
acquire: 11
getaddrinfo: 159754
release: 14
switch: 5
(the numbers above are microseconds). "start" is the time before either
lock is acquired and "switch" is the time after both locks are released.
Maybe the solution for the common case is easier. In the common case of:
s = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
s.bind (('',0))
when you get into setipaddr() name[0] will always be '\0' and so you'll take
the first branch. Do you need all of getaddrinfo()'s bells and whistles to
properly set up addr_ret in this case? At worst, can't the getaddrinfo()
call be made once and then cached?
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4