]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
spelling: asynchronous
authorJosh Soref <jsoref@users.noreply.github.com>
Sun, 23 Jul 2017 15:25:02 +0000 (11:25 -0400)
committerJosh Soref <jsoref@users.noreply.github.com>
Sun, 23 Jul 2017 15:25:02 +0000 (11:25 -0400)
ext/coroutine/coroutine.h
src/lib/asiolink/tests/tcp_socket_unittest.cc
src/lib/dhcp_ddns/ncr_udp.cc
src/lib/dhcpsrv/libdhcpsrv.dox

index 0f36c3f89082992fc902d2835633b809c6048910..612b06b0118488c950da03e6589bd4a82f1001d5 100644 (file)
@@ -20,7 +20,7 @@
 // a single int.
 //
 // A reentrant function contains a CORO_REENTER (coroutine)  { ... }
-// block.  Whenever an asychrnonous operation is initiated within the
+// block.  Whenever an asynchronous operation is initiated within the
 // routine, the function is provided as the handler object.  (The simplest
 // way to do this is to have the reentrant function be the operator()
 // member for the coroutine object itself.)   For example:
index 1e0784d48989b5d546fae95967098877311035da..5d9400a8f85997adf2c54ac57c130940bcf1f341 100644 (file)
@@ -359,7 +359,7 @@ TEST(TCPSocket, sequenceTest) {
 
     // On some operating system the async_connect may return EINPROGRESS.
     // This doesn't neccessarily indicate an error. In most cases trying
-    // to asynchrouonsly write and read from the socket would work just
+    // to asynchronously write and read from the socket would work just
     // fine.
     if ((client_cb.getCode()) != 0 && (client_cb.getCode() != EINPROGRESS)) {
         ADD_FAILURE() << "expected error code of 0 or " << EINPROGRESS
index feaf075abe21d1b18df2e9ecef3f0a53a653869c..655f8b06e6d5322c4cf4c0ecb33a75a4737870ce 100644 (file)
@@ -114,7 +114,7 @@ NameChangeUDPListener::open(isc::asiolink::IOService& io_service) {
 
 void
 NameChangeUDPListener::doReceive() {
-    // Call the socket's asychronous receiving, passing ourself in as callback.
+    // Call the socket's asynchronous receiving, passing ourself in as callback.
     RawBufferPtr recv_buffer = recv_callback_->getBuffer();
     socket_->asyncReceive(recv_buffer.get(), recv_callback_->getBufferSize(),
                           0, recv_callback_->getDataSource().get(),
@@ -294,7 +294,7 @@ NameChangeUDPSender::doSend(NameChangeRequestPtr& ncr) {
     send_callback_->putData(static_cast<const uint8_t*>(ncr_buffer.getData()),
                             ncr_buffer.getLength());
 
-    // Call the socket's asychronous send, passing our callback
+    // Call the socket's asynchronous send, passing our callback
     socket_->asyncSend(send_callback_->getData(), send_callback_->getPutLen(),
                        send_callback_->getDataSource().get(), *send_callback_);
 
index e7470516237a1a856dd5a75c272fae008c5845f0..28b86481f67a22c26f2e0951c3771af45fa319a2 100644 (file)
@@ -288,7 +288,7 @@ on any socket. This poses a problem with running asynchronous calls
 via @c IOService in the main server loop because the @c select()
 blocks for a specified amount of time while asynchronous calls
 are not triggered. In the future we should migrate from the synchronous
-@c select() calls into asynchonous calls using ASIO. Currently,
+@c select() calls into asynchronous calls using ASIO. Currently,
 we mitigate the problem by lowering the @c select() timeout to 1s,
 and polling @c IOService for "ready" timers (handlers) after
 @c select() returns. This may cause delays of "ready" handlers