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 ServerThread that needs to fully stand up before any instance (local or otherwise) of the 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.

Execute the trivial one-task cluster

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

Output

    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 QueueServer interface that is set once start-up is complete. Now in all of the cluster interfaces (LocalCluster, RemoteCluster, AutoScalingCluster, and 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.