Re: [PATCH 2/2] Rename worker threads from xfsdump's documentation

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Aug 10, 2022 at 12:53:33PM +0200, Carlos Maiolino wrote:
> While we've already removed the word 'slave' from the code, the
> documentation should still be updated.
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>

Looks good,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D

> ---
>  doc/xfsdump.html |   38 +++++++++++++++++++-------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/doc/xfsdump.html b/doc/xfsdump.html
> index e37e362..2faa65e 100644
> --- a/doc/xfsdump.html
> +++ b/doc/xfsdump.html
> @@ -286,7 +286,7 @@ of a dump/restore session to multiple drives.
>  	   |      |      |
>  4.	   O      O      O	ring buffers common/ring.[ch]
>             |      |      |
> -5.	 slave  slave   slave	ring_create(... ring_slave_entry ...)
> +5.	worker  worker  worker	ring_create(... ring_worker_entry ...)
>  	thread  thread  thread
>  	   |      |      |
>  6.	 drive  drive   drive	physical drives
> @@ -306,7 +306,7 @@ The process hierachy is shown above. main() first initialises
>  the drive managers with calls to the drive_init functions. In
>  addition to choosing and assigning drive strategies and ops for each
>  drive object, the drive managers intialise a ring buffer and (for
> -devices other than simple UNIX files) sproc off a slave thread that
> +devices other than simple UNIX files) sproc off a worker thread that
>  that handles IO to the tape device. This initialisation happens in the
>  drive_manager code and is not directly visible from main().
>  <p>
> @@ -316,31 +316,31 @@ sprocs. Each child begins execution in childmain(), runs either
>  content_stream_dump or content_stream_restore and exits with the
>  return code from these functions.
>  <p>
> -Both the stream manager processes and the drive manager slaves
> +Both the stream manager processes and the drive manager workers
>  set their signal disposition to ignore HUP, INT, QUIT, PIPE,
>  ALRM, CLD (and for the stream manager TERM as well).
>  <p>
> -The drive manager slave processes are much simpler, and are
> +The drive manager worker processes are much simpler, and are
>  initialised with a call to ring_create, and begin execution in
> -ring_slave_func. The ring structure must also be initialised with
> +ring_worker_func. The ring structure must also be initialised with
>  two ops that are called by the spawned thread: a ring read op, and a write op.
>  The stream manager communicates with the tape manager across this ring
>  structure using Ring_put's and Ring_get's.
>  <p>
> -The slave thread sits in a loop processing messages that come across
> +The worker thread sits in a loop processing messages that come across
>  the ring buffer. It ignores signals and does not terminate until it
>  receives a RING_OP_DIE message. It then exits 0.
>  <p>
>  The main process sleeps waiting for any of its children to die
>  (ie. waiting for a SIGCLD). All children that it cares about (stream
> -managers and ring buffer slaves) are registered through the child
> +managers and ring buffer workers) are registered through the child
>  manager abstraction. When a child dies wait status and other info is
>  stored with its entry in the child manager. main() ignores the deaths
>  of children (and grandchildren) that are not registered through the child
>  manager. The return status of these subprocesses is checked
>  and in the case of an error is used to determine the overall exit code.
>  <p>
> -We do not expect slave threads to ever die unexpectedly: they ignore
> +We do not expect worker threads to ever die unexpectedly: they ignore
>  most signals and only exit when they receive a RING_OP_DIE at which
>  point they drop out of the message processing loop and always signal success.
>  <p>
> @@ -1680,35 +1680,35 @@ If xfsdump/xfsrestore is running single-threaded (-Z option)
>  or is running on Linux (which is not multi-threaded) then
>  records are read/written straight to the tape. If it is running
>  multi-threaded then a circular buffer is used as an intermediary
> -between the client and slave threads.
> +between the client and worker threads.
>  <p>
>  Initially <i>drive_init1()</i> calls <i>ds_instantiate()</i> which
>  if dump/restore is running multi-threaded,
>  creates the ring buffer with <i>ring_create</i> which initialises
> -the state to RING_STAT_INIT and sets up the slave thread with
> -ring_slave_entry.
> +the state to RING_STAT_INIT and sets up the worker thread with
> +ring_worker_entry.
>  <pre>
>  ds_instantiate()
>    ring_create(...,ring_read, ring_write,...)
>      - allocate and init buffers
>      - set rm_stat = RING_STAT_INIT
> -    start up slave thread with ring_slave_entry
> +    start up worker thread with ring_worker_entry
>  </pre>
> -The slave spends its time in a loop getting items from the
> +The worker spends its time in a loop getting items from the
>  active queue, doing the read or write operation and placing the result
>  back on the ready queue.
>  <pre>
> -slave
> +worker
>  ======
> -ring_slave_entry()
> +ring_worker_entry()
>    loop
> -    ring_slave_get() - get from active queue
> +    ring_worker_get() - get from active queue
>      case rm_op
>        RING_OP_READ -> ringp->r_readfunc
>        RING_OP_WRITE -> ringp->r_writefunc
>        ..
>      endcase
> -    ring_slave_put() - puts on ready queue
> +    ring_worker_put() - puts on ready queue
>    endloop
>  </pre>
>  
> @@ -1778,7 +1778,7 @@ prepare_drive()
>  <p>
>  For each <i>do_read</i> call in the multi-threaded case,
>  we have two sides to the story: the client which is coming
> -from code in <i>content.c</i> and the slave which is a simple
> +from code in <i>content.c</i> and the worker which is a simple
>  thread just satisfying I/O requests.
>  From the point of view of the ring buffer, these are the steps
>  which happen for reading:
> @@ -1786,7 +1786,7 @@ which happen for reading:
>  <li>client removes msg from ready queue
>  <li>client wants to read, so sets op field to READ (RING_OP_READ)
>     and puts on active queue
> -<li>slave removes msg from active queue,
> +<li>worker removes msg from active queue,
>     invokes client read function,
>     sets status field: OK/ERROR,
>     puts msg on ready queue
> 
>