Browse Source

spelling: asynchronous

Josh Soref 8 years ago
parent
commit
b741973f95

+ 1 - 1
ext/coroutine/coroutine.h

@@ -20,7 +20,7 @@
 // a single int.
 // a single int.
 //
 //
 // A reentrant function contains a CORO_REENTER (coroutine)  { ... }
 // 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
 // routine, the function is provided as the handler object.  (The simplest
 // way to do this is to have the reentrant function be the operator()
 // way to do this is to have the reentrant function be the operator()
 // member for the coroutine object itself.)   For example:
 // member for the coroutine object itself.)   For example:

+ 1 - 1
src/lib/asiolink/tests/tcp_socket_unittest.cc

@@ -359,7 +359,7 @@ TEST(TCPSocket, sequenceTest) {
 
 
     // On some operating system the async_connect may return EINPROGRESS.
     // On some operating system the async_connect may return EINPROGRESS.
     // This doesn't neccessarily indicate an error. In most cases trying
     // 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.
     // fine.
     if ((client_cb.getCode()) != 0 && (client_cb.getCode() != EINPROGRESS)) {
     if ((client_cb.getCode()) != 0 && (client_cb.getCode() != EINPROGRESS)) {
         ADD_FAILURE() << "expected error code of 0 or " << EINPROGRESS
         ADD_FAILURE() << "expected error code of 0 or " << EINPROGRESS

+ 2 - 2
src/lib/dhcp_ddns/ncr_udp.cc

@@ -114,7 +114,7 @@ NameChangeUDPListener::open(isc::asiolink::IOService& io_service) {
 
 
 void
 void
 NameChangeUDPListener::doReceive() {
 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();
     RawBufferPtr recv_buffer = recv_callback_->getBuffer();
     socket_->asyncReceive(recv_buffer.get(), recv_callback_->getBufferSize(),
     socket_->asyncReceive(recv_buffer.get(), recv_callback_->getBufferSize(),
                           0, recv_callback_->getDataSource().get(),
                           0, recv_callback_->getDataSource().get(),
@@ -294,7 +294,7 @@ NameChangeUDPSender::doSend(NameChangeRequestPtr& ncr) {
     send_callback_->putData(static_cast<const uint8_t*>(ncr_buffer.getData()),
     send_callback_->putData(static_cast<const uint8_t*>(ncr_buffer.getData()),
                             ncr_buffer.getLength());
                             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(),
     socket_->asyncSend(send_callback_->getData(), send_callback_->getPutLen(),
                        send_callback_->getDataSource().get(), *send_callback_);
                        send_callback_->getDataSource().get(), *send_callback_);
 
 

+ 1 - 1
src/lib/dhcpsrv/libdhcpsrv.dox

@@ -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()
 via @c IOService in the main server loop because the @c select()
 blocks for a specified amount of time while asynchronous calls
 blocks for a specified amount of time while asynchronous calls
 are not triggered. In the future we should migrate from the synchronous
 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,
 we mitigate the problem by lowering the @c select() timeout to 1s,
 and polling @c IOService for "ready" timers (handlers) after
 and polling @c IOService for "ready" timers (handlers) after
 @c select() returns. This may cause delays of "ready" handlers
 @c select() returns. This may cause delays of "ready" handlers