mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-01 22:45:18 +00:00
Code Issues Releases Wiki Activity

spelling: asynchronous

Browse Source
This commit is contained in:
Josh Soref
2017-07-23 11:25:02 -04:00
parent 1a791d0ad1
commit b741973f95
4 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
ext/coroutine/coroutine.h
View File

@@ -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:

2
src/lib/asiolink/tests/tcp_socket_unittest.cc
View File

@@ -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

4
src/lib/dhcp_ddns/ncr_udp.cc
View File

@@ -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_);

2
src/lib/dhcpsrv/libdhcpsrv.dox
View 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() 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