Replay progress report

[Hal Murray]

esr at thyrsus.com said:
> I considered doing it that way.  The problem is that if you multithread the
> DNS lookups, the order in which the capture events land is no longer
> deterministic. At that point the minimum complexity required of the replay
> interpreter *explodes*.  I chose to dodge that lest I find myself down a
> rathole. 

Let me try again.

If you want replay to handle the pool case, then you have to handle the 
asynchronous DNS case.  I think the pool case is important, but it can wait 
until you get a simple case working.

I think the asynchronous DNS is just like processing packets.  The idea is to 
work at the edges of the main thread and ignore the DNS thread.  (Intercept 
might have to ignore logging from the DNS thread.  Daniel added a lock in the 
logging a while ago.  It was discovered due to mangled logging so there is 
some logging from the DNS thread.)

Recording the DNS request is similar to recording transmit packets.  Replay 
compares the current request with the next line in the log file.

Processing the DNS result is like processing a receive packet.  Record has to 
intercept where the main thread pulls the result off the queue.  When replay 
finds a DNS result in the log file, it has to do whatever the main thread 
does with the result.



-- 
These are my opinions.  I hate spam.