diff options
Diffstat (limited to 'doc/developer')
| -rw-r--r-- | doc/developer/logging.rst | 8 | ||||
| -rw-r--r-- | doc/developer/modules.rst | 4 | ||||
| -rw-r--r-- | doc/developer/path-internals-pcep.rst | 2 | ||||
| -rw-r--r-- | doc/developer/process-architecture.rst | 36 | ||||
| -rw-r--r-- | doc/developer/rcu.rst | 2 | ||||
| -rw-r--r-- | doc/developer/tracing.rst | 4 |
6 files changed, 28 insertions, 28 deletions
diff --git a/doc/developer/logging.rst b/doc/developer/logging.rst index e262f6af94..b7021b69a1 100644 --- a/doc/developer/logging.rst +++ b/doc/developer/logging.rst @@ -335,16 +335,16 @@ Time/interval formats FRR library helper formats ^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. frrfmt:: %pTH (struct thread *) +.. frrfmt:: %pTH (struct event *) - Print remaining time on timer thread. Interval-printing flag characters + Print remaining time on timer event. Interval-printing flag characters listed above for ``%pTV`` can be added, e.g. ``%pTHtx``. ``NULL`` pointers are printed as ``-``. -.. frrfmt:: %pTHD (struct thread *) +.. frrfmt:: %pTHD (struct event *) - Print debugging information for given thread. Sample output: + Print debugging information for given event. Sample output: .. code-block:: none diff --git a/doc/developer/modules.rst b/doc/developer/modules.rst index e95f8a1b4a..0feac8e738 100644 --- a/doc/developer/modules.rst +++ b/doc/developer/modules.rst @@ -56,9 +56,9 @@ Basic boilerplate: #include "hook.h" #include "module.h" #include "libfrr.h" - #include "thread.h" + #include "frrevent.h" - static int module_late_init(struct thread_master *master) + static int module_late_init(struct event_loop *master) { /* Do initialization stuff here */ return 0; diff --git a/doc/developer/path-internals-pcep.rst b/doc/developer/path-internals-pcep.rst index ca318314f1..a6b22204c2 100644 --- a/doc/developer/path-internals-pcep.rst +++ b/doc/developer/path-internals-pcep.rst @@ -182,7 +182,7 @@ The controller is defined and implemented in `path_pcep_controller.[hc]`. Part of the controller code runs in FRR main thread and part runs in its own FRR pthread started to isolate the main thread from the PCCs' event loop. To communicate between the threads it uses FRR events, timers and -`thread_execute` calls. +`event_execute` calls. PCC diff --git a/doc/developer/process-architecture.rst b/doc/developer/process-architecture.rst index 37bd620f24..33ef278c4d 100644 --- a/doc/developer/process-architecture.rst +++ b/doc/developer/process-architecture.rst @@ -28,7 +28,7 @@ within the event system are variations on the term "thread". The primary datastructure that holds the state of an event loop in this system is called a "threadmaster". Events scheduled on the event loop - what would today be called an 'event' or 'task' in systems such as libevent - are called "threads" and the -datastructure for them is ``struct thread``. To add to the confusion, these +datastructure for them is ``struct event``. To add to the confusion, these "threads" have various types, one of which is "event". To hopefully avoid some of this confusion, this document refers to these "threads" as a 'task' except where the datastructures are explicitly named. When they are explicitly named, @@ -47,7 +47,7 @@ section. For now it provides basic information necessary to understand the interplay between the event system and kernel threads. The core event system is implemented in :file:`lib/thread.[ch]`. The primary -structure is ``struct thread_master``, hereafter referred to as a +structure is ``struct event_loop``, hereafter referred to as a ``threadmaster``. A ``threadmaster`` is a global state object, or context, that holds all the tasks currently pending execution as well as statistics on tasks that have already executed. The event system is driven by adding tasks to this @@ -57,7 +57,7 @@ execute. At initialization, a daemon will typically create one fetch each task and execute it. These tasks have various types corresponding to their general action. The types -are given by integer macros in :file:`thread.h` and are: +are given by integer macros in :file:`event.h` and are: ``THREAD_READ`` Task which waits for a file descriptor to become ready for reading and then @@ -80,8 +80,8 @@ are given by integer macros in :file:`thread.h` and are: Type used internally for tasks on the ready queue. ``THREAD_UNUSED`` - Type used internally for ``struct thread`` objects that aren't being used. - The event system pools ``struct thread`` to avoid heap allocations; this is + Type used internally for ``struct event`` objects that aren't being used. + The event system pools ``struct event`` to avoid heap allocations; this is the type they have when they're in the pool. ``THREAD_EXECUTE`` @@ -95,9 +95,9 @@ irrelevant for the time being) for the specific type. For example, to add a :: - thread_add_read(struct thread_master *master, int (*handler)(struct thread *), void *arg, int fd, struct thread **ref); + event_add_read(struct event_loop *master, int (*handler)(struct event *), void *arg, int fd, struct event **ref); -The ``struct thread`` is then created and added to the appropriate internal +The ``struct event`` is then created and added to the appropriate internal datastructure within the ``threadmaster``. Note that the ``READ`` and ``WRITE`` tasks are independent - a ``READ`` task only tests for readability, for example. @@ -111,13 +111,13 @@ program. When no more tasks are available, the program dies. Typically at startup the first task added is an I/O task for VTYSH as well as any network sockets needed for peerings or IPC. -To retrieve the next task to run the program calls ``thread_fetch()``. -``thread_fetch()`` internally computes which task to execute next based on +To retrieve the next task to run the program calls ``event_fetch()``. +``event_fetch()`` internally computes which task to execute next based on rudimentary priority logic. Events (type ``THREAD_EVENT``) execute with the highest priority, followed by expired timers and finally I/O tasks (type ``THREAD_READ`` and ``THREAD_WRITE``). When scheduling a task a function and an -arbitrary argument are provided. The task returned from ``thread_fetch()`` is -then executed with ``thread_call()``. +arbitrary argument are provided. The task returned from ``event_fetch()`` is +then executed with ``event_call()``. The following diagram illustrates a simplified version of this infrastructure. @@ -133,18 +133,18 @@ illustrated at the bottom. Mapping the general names used in the figure to specific FRR functions: -- ``task`` is ``struct thread *`` -- ``fetch`` is ``thread_fetch()`` -- ``exec()`` is ``thread_call`` -- ``cancel()`` is ``thread_cancel()`` -- ``schedule()`` is any of the various task-specific ``thread_add_*`` functions +- ``task`` is ``struct event *`` +- ``fetch`` is ``event_fetch()`` +- ``exec()`` is ``event_call`` +- ``cancel()`` is ``event_cancel()`` +- ``schedule()`` is any of the various task-specific ``event_add_*`` functions Adding tasks is done with various task-specific function-like macros. These macros wrap underlying functions in :file:`thread.c` to provide additional information added at compile time, such as the line number the task was scheduled from, that can be accessed at runtime for debugging, logging and informational purposes. Each task type has its own specific scheduling function -that follow the naming convention ``thread_add_<type>``; see :file:`thread.h` +that follow the naming convention ``event_add_<type>``; see :file:`event.h` for details. There are some gotchas to keep in mind: @@ -228,7 +228,7 @@ well as *any other pthread*. This serves as the basis for inter-thread communication and boils down to a slightly more complicated method of message passing, where the messages are the regular task events as used in the event-driven model. The only difference is thread cancellation, which requires -calling ``thread_cancel_async()`` instead of ``thread_cancel`` to cancel a task +calling ``event_cancel_async()`` instead of ``event_cancel`` to cancel a task currently scheduled on a ``threadmaster`` belonging to a different pthread. This is necessary to avoid race conditions in the specific case where one pthread wants to guarantee that a task on another pthread is cancelled before diff --git a/doc/developer/rcu.rst b/doc/developer/rcu.rst index ac4405121e..4fd56587ae 100644 --- a/doc/developer/rcu.rst +++ b/doc/developer/rcu.rst @@ -120,7 +120,7 @@ atomic ops & datastructures with other types of locking, e.g. rwlocks. The ``thread_master`` code currently always holds RCU everywhere, except while doing the actual ``poll()`` syscall. This is both an optimization as well as an "easement" into getting RCU going. The current implementation - contract is that any ``struct thread *`` callback is called with a RCU + contract is that any ``struct event *`` callback is called with a RCU holding depth of 1, and that this is owned by the thread so it may (should) drop and reacquire it when doing some longer-running work. diff --git a/doc/developer/tracing.rst b/doc/developer/tracing.rst index 63b04585f1..76f6004034 100644 --- a/doc/developer/tracing.rst +++ b/doc/developer/tracing.rst @@ -150,8 +150,8 @@ Example:: frr_libfrr:frr_pthread_stop (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) frr_libfrr:frr_pthread_run (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) frr_libfrr:thread_call (loglevel: TRACE_INFO (6)) (type: tracepoint) - frr_libfrr:thread_cancel_async (loglevel: TRACE_INFO (6)) (type: tracepoint) - frr_libfrr:thread_cancel (loglevel: TRACE_INFO (6)) (type: tracepoint) + frr_libfrr:event_cancel_async (loglevel: TRACE_INFO (6)) (type: tracepoint) + frr_libfrr:event_cancel (loglevel: TRACE_INFO (6)) (type: tracepoint) frr_libfrr:schedule_write (loglevel: TRACE_INFO (6)) (type: tracepoint) frr_libfrr:schedule_read (loglevel: TRACE_INFO (6)) (type: tracepoint) frr_libfrr:schedule_event (loglevel: TRACE_INFO (6)) (type: tracepoint) |