[Python-Dev] New branch for r23c2 work

Skip Montanaro skip@pobox.com
Mon, 21 Jul 2003 17:36:37 -0500

    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?