| Server IP : 85.214.239.14 / Your IP : 3.12.36.130 Web Server : Apache/2.4.62 (Debian) System : Linux h2886529.stratoserver.net 4.9.0 #1 SMP Tue Jan 9 19:45:01 MSK 2024 x86_64 User : www-data ( 33) PHP Version : 7.4.18 Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, MySQL : OFF | cURL : OFF | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : OFF Directory : /proc/3/root/usr/share/doc/libmail-dkim-perl/ |
Upload File : |
Strategies for Asynchronous DNS
-------------------------------
Principles
1. As soon as we can tell what to query, initiate the query.
2. Design things so that the results of the query aren't needed
until later in the process.
Three different strategies?
A. Have the query_async() call return a token that can be used by
a later function to get the actual result of the query.
The "token" can actually be a subroutine that when called,
produces the result of the query.
B. Have the query_async() call not return anything, but the result
will be cached so a later call can get the result of the query
by passing in the same query parameters.
C. Have the query_async() call take an extra parameter, a reference
to a callback function... i.e. a function that will be called
whenever the query finishes, with the result of the query.
I think I prefer strategy A to B; it's more standard of a practice.
One trick about A is knowing where to store the "token".
I'm not sure yet about A vs C.
C fits in more naturally with coroutines and continuations.
Might make the code more simple, but I need another function that
will block until the query is finished.