Commit b741973f authored by Josh Soref's avatar Josh Soref

spelling: asynchronous

parent 1a791d0a
......@@ -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:
......
......@@ -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
......
......@@ -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_);
......
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment