[Zope] Asynchronous DTML

Chris McDonough chrism@zope.com
Thu, 04 Oct 2001 23:24:47 -0400

Well, this is all news to me.  ;-)  Maybe this has something to do with 
the problem that kicked off this thread.

I thought that the BSD calls had implied threadsafety.  But I guess they 
don't from your description.  But in this case, if there was no lock 
inside the system call, why do the calls serialize?  You would think 
that they'd go right ahead and make a mess of things, but explicitly 
*not* block if they weren't threadsafe.

All of this is kinda dumb.  I want a system to think about all this for 
me and do the right thing. I've paid my dues already. ;-)

- C

Andrew Kenneth Milton wrote:
> +-------[ Chris McDonough ]----------------------
> | It depends on the host system's gethostbyaddr, I suppose.  Is there a 
> | reason you can't concurrently do more than one DNS lookup that you can 
> | think of?
> Well first you're in a system call, so your whole process will block while
> it's inside kernel space, especially on those systems whose kernels don't
> have threaded kernels. If it takes two minutes for your systemcall to
> complete, then your process will block for two minutes. gethostbyname also 
> uses static storage to return results. This is why Netscape, Squid, Mozilla 
> et. al have DNS helper applications that do DNS lookups in a seperate forked 
> process (not thread). They also have alarms around it to interrupt the
> call after about 30 seconds, since it's probably not coming back if it
> takes that long.
> You have to explicitly use gethostbyname_r to get the MP-Safe resolver,
> I don't know if Python does this (I'm not a python internals guru), that's
> why I ask. Calling _r routines doesn't guarantee that you'll get concurrent
> lookups either, it just means that multiple threads calling gethostbyname_r
> won't trash each other.

Chris McDonough                    Zope Corporation
http://www.zope.org             http://www.zope.com
"Killing hundreds of birds with thousands of stones"