> > > > > You could run a small pool > > > > > (1 or more) of processes each of which handles multiple concurrent > > > > > smtpd connections. > > > > > > > > Sorry, sort of beginner programmer question, to be clear > > > > what you say, concurrent connections would be handled by > > > > a policy server by spawning a new thread when a new connection > > > > is made? I can see this could solve problem if all threads see > > > > the same DB connection. > > > > > > No, I was thinking non-blocking event-based concurrency in a single > > > thread. > > > > Hmm sounds impossible - how can single thread do more than one > > thing at a time? Guess I have some google-ing to do, learn how > > single thread could use events to handle more than one request > > at same time. > > One thread monitors multiple file handles (event sources), and > processes events one at a time. Examples of events are client > requests and DNS replies. This is how postscreen is implemented.
OK, so concurrent in that you could start accepting a new SMTP session while an earlier one is waiting on a DNS lookup? That mean that the code has to put the SMTP session into a saved/wait state while DNS request is made so thread can move to next available select? I was afraid there still just one thread so literally no concurrent processing (opposed to threads/fork) but there is only one postscreen process so good evidence this is a fast model! Reason must be that SMTP conversation is trivial and fast, only time consuming part is tings like extrnal lookups (so is another event any database lookup?). Thanks for the tips!!!
