+-------[ 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|