mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-08-31 05:55:28 +00:00
spelling: asynchronous
This commit is contained in:
@@ -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
|
||||
|
Reference in New Issue
Block a user