.. _20240706_2_5_2_release:

Release Notes (v2.5.2)
======================

`July 7, 2024`

The v2.5.2 release includes important bug fixes and minor improvements.

- Fix signal handling regression on Windows
- Improve start-time performance

-----

Features
--------

|

Improved start-time performance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For all prior v2 releases of the software, when starting the ``hs cluster``,
the implementation of the underlying "cluster" interface includes an instance of
the :class:`~hypershell.server.ServerThread` that needs to fully stand up before
any instance (local or otherwise) of the :class:`~hypershell.client.ClientThread`
can connect back. Without any hard mechanism to check, we simply included a fixed
2-second sleep phase to ensure the server had time before launching clients.

In practice, this means that even the most trivial, ad-hoc scenario of launching
the cluster with a single task resulted in many seconds; imparting an unnecessary
sense of heft to the user.

For example (on Linux), the following case takes more than 4 seconds, entirely
occupied by the program and not the task.

.. admonition:: Execute the trivial one-task cluster
    :class: note

    .. code-block:: shell

        time seq 1 | hs cluster -t 'echo {}' --no-db --no-confirm

    .. details:: Output

        .. code-block:: none

                INFO [hypershell.client] Running task (f3596546-e6f9-4b28-9ef6-e7212a63e5ca)
            1
            seq 1  0.00s user 0.00s system 71% cpu 0.002 total
            hs cluster -t 'echo {}' --no-db --no-confirm  0.57s user 0.09s system 38% cpu 1.733 total

We added a simple `ready` flag on the underlying :class:`~hypershell.core.queue.QueueServer`
interface that is set once start-up is complete. Now in all of the cluster interfaces
(:class:`~hypershell.cluster.local.LocalCluster`, :class:`~hypershell.cluster.remote.RemoteCluster`,
:class:`~hypershell.cluster.remote.AutoScalingCluster`, and :class:`~hypershell.cluster.ssh.SSHCluster`)
we have a tight polling loop on that flag allowing not only a shorter wait time before proceeding
with client launch but *correctness* (though this was never an issue in practice).

That 2-second period is now entirely eliminated resulting in a total runtime of less than 2 seconds
in the above example. Ideally this would still be much less, but the overhead from Python
cannot be avoided, incurred by the import mechanics of all the modules on the file system.

|

-----

Fixes
-----

|

Windows platform fix for signal handling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The program failed to start after the signal handling feature was added in v2.5.0.
On Windows, the ``SIGUSR1`` and ``SIGUSR2`` signals (and others) do not exist.
The fix simply allows for this feature to passively be ignored on Windows.

|