On Thursday 30 March 2006 00:43, Rian A Hunter wrote: > > For my purposes I need a synchronous resolver since I create a thread > anyway, and the work I plan to do isn't high-priority.
Heh. Async mail; I wouldn't have posted my last message if this one had reached me :-) Of course, what I was referring to was not fully async but rather simple nonblocking resolution and an EAGAIN return status. > * You give the API a callback and expect it to call your callback with > the query > data on a separate thread. (this assumes threads) Hmmm. I wonder what introducing separate threads here might reveal? That use of threads would seem to be incompatible with, for example, a Tcl interpreter, since that is documented as being unsafe to use willy-nilly in multiple threads. > * The API works in some other process abstraction (through a process, > or thread > or mystery) and when processing in your thread absolutely needs the query data > you do ask the API if it's done yet. I like that better. You're keeping any threading issues hidden in the APR calls, so the applications layer stays simple. > * Your idea here Whatever you do, I think it should have simpleminded versions for plain blocking calls or nonblocking with EAGAIN. -- Nick Kew
