-/** Used to resolve sql server hostnames
- */
-class SQLresolver : public Resolver
-{
- private:
- SQLhost host;
- SQLhost confhost;
- Module* mod;
- public:
- SQLresolver(Module* m, InspIRCd* Instance, const SQLhost& hi, const SQLhost& ci)
- : Resolver(Instance, hi.host, DNS_QUERY_FORWARD, (Module*)m), host(hi), confhost(ci), mod(m)
- {
- }
-
- virtual void OnLookupComplete(const std::string &result);
-
- virtual void OnError(ResolverError e, const std::string &errormessage)
- {
- ServerInstance->Log(DEBUG, "DNS lookup failed (%s), dying horribly", errormessage.c_str());
- }
-};
-
-/** QueryQueue, a queue of queries waiting to be executed.
- * This maintains two queues internally, one for 'priority'
- * queries and one for less important ones. Each queue has
- * new queries appended to it and ones to execute are popped
- * off the front. This keeps them flowing round nicely and no
- * query should ever get 'stuck' for too long. If there are
- * queries in the priority queue they will be executed first,
- * 'unimportant' queries will only be executed when the
- * priority queue is empty.
- *
- * We store lists of SQLrequest's here, by value as we want to avoid storing
- * any data allocated inside the client module (in case that module is unloaded
- * while the query is in progress).
- *
- * Because we want to work on the current SQLrequest in-situ, we need a way
- * of accessing the request we are currently processing, QueryQueue::front(),
- * but that call needs to always return the same request until that request
- * is removed from the queue, this is what the 'which' variable is. New queries are
- * always added to the back of one of the two queues, but if when front()
- * is first called then the priority queue is empty then front() will return
- * a query from the normal queue, but if a query is then added to the priority
- * queue then front() must continue to return the front of the *normal* queue
- * until pop() is called.