Replay progress report
hmurray at megapathdsl.net
Mon Jan 4 09:18:07 UTC 2016
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
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.
More information about the devel