mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-24 19:18:50 +00:00
Code Issues Releases Wiki Activity
bind/lib/isc/job_p.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

44 lines
1.2 KiB
C
Raw Permalink Normal View History

New event loop handling API This commit introduces new APIs for applications and signal handling, intended to replace isc_app for applications built on top of libisc. * isc_app will be replaced with isc_loopmgr, which handles the starting and stopping of applications. In isc_loopmgr, the main thread is not blocked, but is part of the working thread set. The loop manager will start a number of threads, each with a uv_loop event loop running. Setup and teardown functions can be assigned which will run when the loop starts and stops, and jobs can be scheduled to run in the meantime. When isc_loopmgr_shutdown() is run from any the loops, all loops will shut down and the application can terminate. * signal handling will now be handled with a separate isc_signal unit. isc_loopmgr only handles SIGTERM and SIGINT for application termination, but the application may install additional signal handlers, such as SIGHUP as a signal to reload configuration. * new job running primitives, isc_job and isc_async, have been added. Both units schedule callbacks (specifying a callback function and argument) on an event loop. The difference is that isc_job unit is unlocked and not thread-safe, so it can be used to efficiently run jobs in the same thread, while isc_async is thread-safe and uses locking, so it can be used to pass jobs from one thread to another. * isc_tid will be used to track the thread ID in isc_loop worker threads. * unit tests have been added for the new APIs.
2022-07-26 13:03:22 +02:00
/*
* Copyright (C) Internet Systems Consortium, Inc. ("ISC")
*
* SPDX-License-Identifier: MPL-2.0
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, you can obtain one at https://mozilla.org/MPL/2.0/.
*
* See the COPYRIGHT file distributed with this work for additional
* information regarding copyright ownership.
*/
#pragma once
#include <isc/job.h>
#include <isc/loop.h>
Change the isc_async API to use cds_wfcqueue internally The isc_async API was using lock-free stack (where enqueue operation was not wait-free). Change the isc_async to use cds_wfcqueue internally - enqueue and splice (move the queue members from one list to another) is nonblocking and wait-free.
2023-05-08 23:31:54 +02:00
#include <isc/os.h>
Refactor isc_job_run to not-make any allocations Change the isc_job_run() to not-make any allocations. The caller must make sure that it allocates isc_job_t - usually as part of the argument passed to the callback. For simple jobs, using isc_async_run() is advised as it allocates its own separate isc_job_t.
2023-03-27 22:40:57 +02:00
#include <isc/uv.h>
New event loop handling API This commit introduces new APIs for applications and signal handling, intended to replace isc_app for applications built on top of libisc. * isc_app will be replaced with isc_loopmgr, which handles the starting and stopping of applications. In isc_loopmgr, the main thread is not blocked, but is part of the working thread set. The loop manager will start a number of threads, each with a uv_loop event loop running. Setup and teardown functions can be assigned which will run when the loop starts and stops, and jobs can be scheduled to run in the meantime. When isc_loopmgr_shutdown() is run from any the loops, all loops will shut down and the application can terminate. * signal handling will now be handled with a separate isc_signal unit. isc_loopmgr only handles SIGTERM and SIGINT for application termination, but the application may install additional signal handlers, such as SIGHUP as a signal to reload configuration. * new job running primitives, isc_job and isc_async, have been added. Both units schedule callbacks (specifying a callback function and argument) on an event loop. The difference is that isc_job unit is unlocked and not thread-safe, so it can be used to efficiently run jobs in the same thread, while isc_async is thread-safe and uses locking, so it can be used to pass jobs from one thread to another. * isc_tid will be used to track the thread ID in isc_loop worker threads. * unit tests have been added for the new APIs.
2022-07-26 13:03:22 +02:00
Change the isc_async API to use cds_wfcqueue internally The isc_async API was using lock-free stack (where enqueue operation was not wait-free). Change the isc_async to use cds_wfcqueue internally - enqueue and splice (move the queue members from one list to another) is nonblocking and wait-free.
2023-05-08 23:31:54 +02:00
/*%
* NOTE: We are using struct __cds_wfcq_head that doesn't have an internal
* mutex, because we are only using enqueue and splice, and those don't need
* any synchronization (see urcu/wfcqueue.h for detailed description).
*/
Use proper padding instead of using alignas() As it was pointed out, the alignas() can't be used on objects larger than `max_align_t` otherwise the compiler might miscompile the code to use auto-vectorization on unaligned memory. As we were only using alignas() as a way to prevent false memory sharing, we can use manual padding in the affected structures.
2023-12-04 12:21:33 +01:00
STATIC_ASSERT(ISC_OS_CACHELINE_SIZE >= sizeof(struct __cds_wfcq_head),
"ISC_OS_CACHELINE_SIZE smaller than "
"sizeof(struct __cds_wfcq_head)");
Change the isc_async API to use cds_wfcqueue internally The isc_async API was using lock-free stack (where enqueue operation was not wait-free). Change the isc_async to use cds_wfcqueue internally - enqueue and splice (move the queue members from one list to another) is nonblocking and wait-free.
2023-05-08 23:31:54 +02:00
typedef struct isc_jobqueue {
Use proper padding instead of using alignas() As it was pointed out, the alignas() can't be used on objects larger than `max_align_t` otherwise the compiler might miscompile the code to use auto-vectorization on unaligned memory. As we were only using alignas() as a way to prevent false memory sharing, we can use manual padding in the affected structures.
2023-12-04 12:21:33 +01:00
struct __cds_wfcq_head head;
uint8_t __padding[ISC_OS_CACHELINE_SIZE -
sizeof(struct __cds_wfcq_head)];
struct cds_wfcq_tail tail;
Change the isc_async API to use cds_wfcqueue internally The isc_async API was using lock-free stack (where enqueue operation was not wait-free). Change the isc_async to use cds_wfcqueue internally - enqueue and splice (move the queue members from one list to another) is nonblocking and wait-free.
2023-05-08 23:31:54 +02:00
} isc_jobqueue_t;
Refactor isc_job_run to not-make any allocations Change the isc_job_run() to not-make any allocations. The caller must make sure that it allocates isc_job_t - usually as part of the argument passed to the callback. For simple jobs, using isc_async_run() is advised as it allocates its own separate isc_job_t.
2023-03-27 22:40:57 +02:00
typedef ISC_LIST(isc_job_t) isc_joblist_t;
New event loop handling API This commit introduces new APIs for applications and signal handling, intended to replace isc_app for applications built on top of libisc. * isc_app will be replaced with isc_loopmgr, which handles the starting and stopping of applications. In isc_loopmgr, the main thread is not blocked, but is part of the working thread set. The loop manager will start a number of threads, each with a uv_loop event loop running. Setup and teardown functions can be assigned which will run when the loop starts and stops, and jobs can be scheduled to run in the meantime. When isc_loopmgr_shutdown() is run from any the loops, all loops will shut down and the application can terminate. * signal handling will now be handled with a separate isc_signal unit. isc_loopmgr only handles SIGTERM and SIGINT for application termination, but the application may install additional signal handlers, such as SIGHUP as a signal to reload configuration. * new job running primitives, isc_job and isc_async, have been added. Both units schedule callbacks (specifying a callback function and argument) on an event loop. The difference is that isc_job unit is unlocked and not thread-safe, so it can be used to efficiently run jobs in the same thread, while isc_async is thread-safe and uses locking, so it can be used to pass jobs from one thread to another. * isc_tid will be used to track the thread ID in isc_loop worker threads. * unit tests have been added for the new APIs.
2022-07-26 13:03:22 +02:00
void
Refactor isc_job_run to not-make any allocations Change the isc_job_run() to not-make any allocations. The caller must make sure that it allocates isc_job_t - usually as part of the argument passed to the callback. For simple jobs, using isc_async_run() is advised as it allocates its own separate isc_job_t.
2023-03-27 22:40:57 +02:00
isc__job_cb(uv_idle_t *handle);
New event loop handling API This commit introduces new APIs for applications and signal handling, intended to replace isc_app for applications built on top of libisc. * isc_app will be replaced with isc_loopmgr, which handles the starting and stopping of applications. In isc_loopmgr, the main thread is not blocked, but is part of the working thread set. The loop manager will start a number of threads, each with a uv_loop event loop running. Setup and teardown functions can be assigned which will run when the loop starts and stops, and jobs can be scheduled to run in the meantime. When isc_loopmgr_shutdown() is run from any the loops, all loops will shut down and the application can terminate. * signal handling will now be handled with a separate isc_signal unit. isc_loopmgr only handles SIGTERM and SIGINT for application termination, but the application may install additional signal handlers, such as SIGHUP as a signal to reload configuration. * new job running primitives, isc_job and isc_async, have been added. Both units schedule callbacks (specifying a callback function and argument) on an event loop. The difference is that isc_job unit is unlocked and not thread-safe, so it can be used to efficiently run jobs in the same thread, while isc_async is thread-safe and uses locking, so it can be used to pass jobs from one thread to another. * isc_tid will be used to track the thread ID in isc_loop worker threads. * unit tests have been added for the new APIs.
2022-07-26 13:03:22 +02:00
void
Refactor isc_job_run to not-make any allocations Change the isc_job_run() to not-make any allocations. The caller must make sure that it allocates isc_job_t - usually as part of the argument passed to the callback. For simple jobs, using isc_async_run() is advised as it allocates its own separate isc_job_t.
2023-03-27 22:40:57 +02:00
isc__job_close(uv_handle_t *handle);
Reference in New Issue Copy Permalink