[Zope] Asynchronous DTML

[Andrew Kenneth Milton]

+-------[ Chris McDonough ]----------------------
| Well, this is all news to me.  ;-)  Maybe this has something to do with 
| the problem that kicked off this thread.

That's what I figured d;)

| 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? 

All (userland) threads live in the same context as your process. When you 
enter kernel space, you're off the run queue. Deschedule the *context* 
you block all threads. This is why, in general, userland thread suck eggs 
like grandma.

There's two different types of threads (that we're concerned with)

a) Userland threads -- live in the context of your process
b) Kernel threads   -- individually schedulable threads (to the kernel)

There are obviously different strains and hybrids, but, let's keep it
simple d8)

If you can get one of b) you can do all your lookups inside that without
blocking your main context. There aren't a lot of b) implementations
around, which is why a seperate process is spawned just for lookups.

| You would think 
| that they'd go right ahead and make a mess of things, but explicitly 
| *not* block if they weren't threadsafe.

They do. If you have two threads doing lookups (that we know are going
to return quickly), they'll happily trash each others data as fast as
you can do the queries (unless you use the _r ones of course)

It doesn't matter if a system call is threadsafe, going into the kernel 
blocks your current context. Most of the time syscalls are quick. Looking up 
non-existant domain names, or IPs that don't resolve can take up to 
two minutes to timeout.

-- 
Totally Holistic Enterprises Internet|                      | Andrew Milton
The Internet (Aust) Pty Ltd          |                      |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068    |akm@theinternet.com.au|