fixed spelling and added spell checking to actions (#38)

Fixed spelling and added spell-checking action

.codespellrc

@@ -0,0 +1,6 @@
+# Ref: https://github.com/codespell-project/codespell#using-a-config-file
+[codespell]
+skip = .git,.codespellrc
+check-hidden = true
+# ignore-regex = 
+ignore-words-list = te

.github/workflows/codespell.yml

@@ -0,0 +1,14 @@
+# GitHub Action to automate the identification of common misspellings in text files
+# https://github.com/codespell-project/codespell
+# https://github.com/codespell-project/actions-codespell
+name: codespell
+on: [push, pull_request]
+permissions:
+  contents: read
+jobs:
+  codespell:
+    name: Check for spelling errors
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/[email protected]
+      - uses: codespell-project/actions-codespell@master

docs/source/asyncapi.rst

@@ -1,6 +1,6 @@
 Async VOL APIs
 ==============
-Besides the HDF5 EventSet and asynchronous I/O operation APIs, the async VOL connector also provides convinient functions for finer control of the asynchronous I/O operations. Application developers should be very careful with these APIs as they may cause unexpected behavior when not properly used. The "h5_async_lib.h" header file must be included in the application's source code and the static async VOL library (libasynchdf5.a) must be linked.
+Besides the HDF5 EventSet and asynchronous I/O operation APIs, the async VOL connector also provides convenient functions for finer control of the asynchronous I/O operations. Application developers should be very careful with these APIs as they may cause unexpected behavior when not properly used. The "h5_async_lib.h" header file must be included in the application's source code and the static async VOL library (libasynchdf5.a) must be linked.
 
 
 * Set the ``disable implicit`` flag to the property list, which will force all HDF5 I/O operations to be synchronous, even when the HDF5's explicit ``_async`` APIs are used.
@@ -15,11 +15,11 @@ Besides the HDF5 EventSet and asynchronous I/O operation APIs, the async VOL con
     herr_t H5Pget_dxpl_disable_async_implicit(hid_t dxpl, hbool_t *is_disable);
 
 .. note::
-    The ``disable implicit`` flag only becomes effective when the corresponding ``fapl`` or ``dxpl`` is actually used by another HDF5 function call, e.g., with ``H5Fopen`` or ``H5Dwrite``. When a new ``fapl`` or ``dxpl`` is used by any HDF5 function without setting the ``disable implict`` flag, e.g., ``H5P_DEFAULT``, it will reset the mode back to asynchronous execution.
+    The ``disable implicit`` flag only becomes effective when the corresponding ``fapl`` or ``dxpl`` is actually used by another HDF5 function call, e.g., with ``H5Fopen`` or ``H5Dwrite``. When a new ``fapl`` or ``dxpl`` is used by any HDF5 function without setting the ``disable implicit`` flag, e.g., ``H5P_DEFAULT``, it will reset the mode back to asynchronous execution.
 
 .. code-block::
     // Set the pause flag to property list that pauses all asynchronous I/O operations.
-    // Note: similar to the disable implict flag setting, the operations are only paused when
+    // Note: similar to the disable implicit flag setting, the operations are only paused when
     // the dxpl is used by another HDF5 function call.
     herr_t H5Pset_dxpl_pause(hid_t dxpl, hbool_t is_pause);
 
@@ -47,7 +47,7 @@ Besides the HDF5 EventSet and asynchronous I/O operation APIs, the async VOL con
 .. note::
     The operations are only delayed when the dxpl is used by another HDF5 function call.
 
-* Convinient APIs for other stacked VOL connectors
+* Convenient APIs for other stacked VOL connectors
 
 .. warning:: 
     Following APIs are not intended for application use.

docs/source/bestpractice.rst

@@ -8,7 +8,7 @@ To take full advantage of the async I/O VOL connector, applications should have
 Inform async VOL on access pattern
 ----------------------------------
 
-By default, the async VOL detects whether the application is busy issuing HDF5 I/O calls or has moved on to other tasks (e.g., computation). If it finds no HDF5 function is called within a short wait period (600 ms by default), it will start the background thread to execute the tasks in the queue. Such status detection can avoid an effectively synchronous I/O when the application thread and the async VOL background thread acquire the HDF5 global mutex in an interleaved fashion. However, some applications may have larger time gaps than the default wait period between HDF5 function calls and experience partially asynchronous behavior. To avoid this, one can set the following environment variable to disable its active ''wait and check'' mechnism and inform async VOL when to start the async execution, this is especially useful for checkpointing data.
+By default, the async VOL detects whether the application is busy issuing HDF5 I/O calls or has moved on to other tasks (e.g., computation). If it finds no HDF5 function is called within a short wait period (600 ms by default), it will start the background thread to execute the tasks in the queue. Such status detection can avoid an effectively synchronous I/O when the application thread and the async VOL background thread acquire the HDF5 global mutex in an interleaved fashion. However, some applications may have larger time gaps than the default wait period between HDF5 function calls and experience partially asynchronous behavior. To avoid this, one can set the following environment variable to disable its active ''wait and check'' mechanism and inform async VOL when to start the async execution, this is especially useful for checkpointing data.
 
 .. code-block::
 
@@ -24,7 +24,7 @@ By default, the async VOL detects whether the application is busy issuing HDF5 I
 
 Mix sync and async operations
 -----------------------------
-It is generally discouraged to mix sync and async operations in an application, as deadlocks may occur unexpectedly. If it is unavoidable, we recommend to separate the sync and async operations as much as possible (ideally using different HDF5 file IDs, even they are opearting on the same file) and set the following FAPL property for the sync operations:
+It is generally discouraged to mix sync and async operations in an application, as deadlocks may occur unexpectedly. If it is unavoidable, we recommend to separate the sync and async operations as much as possible (ideally using different HDF5 file IDs, even they are operating on the same file) and set the following FAPL property for the sync operations:
 
 .. code-block::
 

docs/source/debug.rst

@@ -54,7 +54,7 @@ Following is an example of the messages printed out. By default, when running in
     [ASYNC VOL DBG] entering push_task_to_abt_pool
     [ASYNC VOL DBG] leaving push_task_to_abt_pool
     [ASYNC VOL DBG] async_file_create waiting to finish all previous tasks
-    [ASYNC ABT DBG] async_file_create_fn: trying to aquire global lock
+    [ASYNC ABT DBG] async_file_create_fn: trying to acquire global lock
     [ASYNC ABT DBG] async_file_create_fn: global lock acquired
 
 .. note::

docs/source/gettingstarted.rst

@@ -185,7 +185,7 @@ If any test fails, check ``async_vol_test.err`` in the test directory for the er
 Implicit mode
 =============
 
-This mode is only recommended for testing. The implicit mode allows an application to enable asynchronous I/O through setting the environemental variables :ref:`Set Environmental Variables` and without any major code change. By default, the HDF5 metadata operations are executed asynchronously, and the dataset operations are executed synchronously.
+This mode is only recommended for testing. The implicit mode allows an application to enable asynchronous I/O through setting the environmental variables :ref:`Set Environmental Variables` and without any major code change. By default, the HDF5 metadata operations are executed asynchronously, and the dataset operations are executed synchronously.
 
 .. note::
     Due to the limitations of the implicit mode, we highly recommend applications to use the explicit mode for the best I/O performance.
@@ -270,7 +270,7 @@ Applications may choose to have async VOL to manage the write buffer consistency
     Async vol checks available system memory before its double buffer allocation at runtime, using get_avphys_pages() and sysconf().
     When there is not enough memory for duplicating the current write buffer, it will not allocate memory and force the current write to be synchronous.
 
-With the double buffering enabled, users can also specify how much memory is allowed for async VOL to allocate, with can be set through an environment variable. When the limit is reached during runtime, async VOL will skip the memory allocation and execute the write synchronously, until previous duplicated buffers are freed after their operation compeleted.
+With the double buffering enabled, users can also specify how much memory is allowed for async VOL to allocate, with can be set through an environment variable. When the limit is reached during runtime, async VOL will skip the memory allocation and execute the write synchronously, until previous duplicated buffers are freed after their operation completed.
 
 .. code-block::
 

docs/source/issue.rst

@@ -3,7 +3,7 @@ Known Issues
 
 Slow performance with metadata heavy workload
 ---------------------------------------------
-Async VOL has additional overhead due to its internal management of asynchronous tasks and the background thread execution. If the application is metadata-intensive, e.g. create thousands of groups, datasets, or attributes, this overhead (~0.001s per operation) becomes comparable to the creation time, and could result in worse performance. There may also be additional overhead due to the *wait and check* mechnism  unless ``HDF5_ASYNC_EXE_*`` is set.
+Async VOL has additional overhead due to its internal management of asynchronous tasks and the background thread execution. If the application is metadata-intensive, e.g. create thousands of groups, datasets, or attributes, this overhead (~0.001s per operation) becomes comparable to the creation time, and could result in worse performance. There may also be additional overhead due to the *wait and check* mechanism  unless ``HDF5_ASYNC_EXE_*`` is set.
 
 ABT_thread_create SegFault
 --------------------------
@@ -20,7 +20,7 @@ When an application has a large number of HDF5 function calls, an error like the
     [ 2] 0 libabt.1.dylib 0x0000000105bdbdc0 ABT_thread_create + 128
     [ 3] 0 libh5async.dylib 0x00000001064bde1f push_task_to_abt_pool + 559
 
-This is due to the default Argobots thread stack size being too small, and can be resovled by setting the environement variable:
+This is due to the default Argobots thread stack size being too small, and can be resolved by setting the environment variable:
 
 .. code-block::
 
@@ -43,7 +43,7 @@ This `patch <https://gist.github.com/houjun/208903d8e6a64e2670754d8ca0f6b548>`_
 
 Synchronous H5Dget_space_async
 ------------------------------
-When an application calls H5Dget_space_async, and uses the dataspace ID immediately, a deadlock may occur occationally. Thus we force synchronous execution for H5Dget_space_async. To re-enable its asynchronous execution, set the following environement variable:
+When an application calls H5Dget_space_async, and uses the dataspace ID immediately, a deadlock may occur occasionally. Thus we force synchronous execution for H5Dget_space_async. To re-enable its asynchronous execution, set the following environment variable:
 
 .. code-block::