github.com/lmorg/murex@v0.0.0-20240217211045-e081c89cd4ef/gen/user-guide/schedulers_doc.yaml (about)

     1  - DocumentID: schedulers
     2    Title: >-
     3      Schedulers
     4    CategoryID: user-guide
     5    Summary: >-
     6      Overview of the different schedulers (or 'run modes') in Murex
     7    Description: |-
     8      There are a few distinct schedulers (or run modes) in Murex which are invoked
     9      by builtin commands. This means you can alter the way commands are executed
    10      dynamically within Murex shell scripts.
    11      
    12      ## Normal
    13  
    14      This is a traditional shell where anything in a pipeline (eg `cmd1 -> cmd2 -> cmd3`)
    15      is executed in parallel. The scheduler only pauses launching new commands when
    16      the last command in any pipeline is still executing. A pipeline could be multiple
    17      commands (like above) or a single command (eg `top`).
    18  
    19      **Normal** is the default run mode. When running in a stricter mode, you can not
    20      reset the run mode back to **normal**. You can, however, switch to `unsafe`.
    21  
    22      ## Unsafe
    23  
    24      This is the same as **normal** except that `unsafe` blocks always return zero
    25      exit numbers. The purpose for this is to enable "normal" like scheduling inside
    26      stricter code blocks that might exit if the last function was a non-zero exit
    27      number.
    28  
    29      ## Try
    30  
    31      This is the weakest of all the stricter run modes. It does check the exit number
    32      to confirm if the last function was successful, but only the last function in
    33      any given pipeline. So in `cmd1 -> cmd2 -> cmd3`, if `cmd1` or `cmd2` fail, the
    34      `try` block doesn't exit.
    35  
    36      The benefit of run mode is that it still supports commands running in parallel.
    37  
    38      ## Try Pipe
    39  
    40      This runs the commands sequentially because the stderr and the exit number of
    41      each command is checked irrespective of whether that command is at the start of
    42      the pipeline (eg `start -> middle -> end`), or anywhere else.
    43  
    44      This offers better coverage of exit numbers but at the cost of parallelisation.
    45  
    46      ## Try Err
    47  
    48      This is similar to `try` and **normal** where commands in a pipeline are run in
    49      parallel. The key difference with `tryerr` is that  Murex validates the stderr
    50      as well as the exit number of the last command in any pipeline.
    51      
    52      If stderr is greater than stdout (per bytes written) **OR** the exit number is
    53      non-zero then the scheduler exits that entire block.
    54  
    55      ## Try Pipe Err
    56  
    57      This runs the commands sequentially because the stderr and the exit number of
    58      each command is checked irrespective of whether that command is at the start of
    59      the pipeline (eg `start -> middle -> end`), or anywhere else.
    60  
    61      Like with `tryerr`, if stderr is greater than stdout (per bytes written) **OR**
    62      the exit number is non-zero then the scheduler exits that entire block. Unlike
    63      with `tryerr`, this check happens on every command rather than the last command
    64      in the pipeline. 
    65    Related:
    66    - try
    67    - trypipe
    68    - tryerr
    69    - trypipeerr
    70    - unsafe
    71    - runmode
    72    - pipeline
    73    - pipe-arrow
    74    - pipe-posix
    75    - pipe-generic
    76    - pipe-err