|  | 
| 1 |  | -<h2 align="middle">Zero Backpressure Semaphore Typescript</h2> | 
|  | 1 | +<h3 align="middle">Zero Backpressure Semaphore Typescript</h2> | 
| 2 | 2 | 
 | 
| 3 | 3 | The `ZeroBackpressureSemaphore` class implements a semaphore for Node.js projects, allowing users to limit the number of concurrently executing jobs.   | 
| 4 | 4 | This implementation does not queue pending jobs, thereby eliminating backpressure. As a result, users have better control over memory footprint, which enhances performance by reducing garbage-collector overhead. | 
| @@ -30,15 +30,7 @@ In contrast, `ZeroBackpressureSemaphore` manages job execution, abstracting away | 
| 30 | 30 | 
 | 
| 31 | 31 | Method names are chosen to clearly convey their functionality. | 
| 32 | 32 | 
 | 
| 33 |  | -## Breaking Change in Version 3.0.0 | 
| 34 |  | - | 
| 35 |  | -In version 3.0.0, the target compatibility has been upgraded from ES6 to ES2020. This change was made to leverage the widespread adoption of ES2020, its native support for async/await, and the use of `Promise.allSettled` within the semaphore. | 
| 36 |  | - | 
| 37 |  | -## Breaking Change in Version 2.0.0 | 
| 38 |  | - | 
| 39 |  | -The only breaking change in this release is the renaming of the method `waitTillAllExecutingJobsAreSettled` to `waitForAllExecutingJobsToComplete` for improved readability. No other changes have been introduced. | 
| 40 |  | - | 
| 41 |  | -## 1st use-case: Multiple Jobs Execution | 
|  | 33 | +## 1st use-case: Multiple Jobs Execution :man_technologist: | 
| 42 | 34 | 
 | 
| 43 | 35 | This semaphore variant excels in eliminating backpressure when dispatching multiple concurrent jobs from the same caller. This pattern is typically observed in **background job services**, such as: | 
| 44 | 36 | - Log File analysis. | 
| @@ -246,7 +238,7 @@ On the other hand, given that the timeout is 30 seconds and a typical job durati | 
| 246 | 238 | 
 | 
| 247 | 239 | As a general rule, `waitForAvailability` is advisable whenever a timeout mechanism is involved, and the timeout period begins **before** the job starts execution. Note that the same effect can be achieved with `startExecution` alone, if the timeout-triggering logic is included in the job itself (such as, consuming a message). Both approaches are valid. | 
| 248 | 240 | 
 | 
| 249 |  | -## 2nd use-case: Single Job Execution | 
|  | 241 | +## 2nd use-case: Single Job Execution :man_technologist: | 
| 250 | 242 | 
 | 
| 251 | 243 | The `waitForCompletion` method is useful for executing a sub-procedure, for which the caller must wait before proceeding with its work. | 
| 252 | 244 | 
 | 
| @@ -319,6 +311,14 @@ To improve readability and maintainability, it is highly recommended to assign a | 
| 319 | 311 | - tokenGenerationSemaphore | 
| 320 | 312 | - azureStorageSemaphore | 
| 321 | 313 | 
 | 
|  | 314 | +## Breaking Change in Version 3.0.0 :boom: | 
|  | 315 | + | 
|  | 316 | +In version 3.0.0, the target compatibility has been upgraded from ES6 to ES2020. This change was made to leverage the widespread adoption of ES2020, its native support for async/await, and the use of `Promise.allSettled` within the semaphore. | 
|  | 317 | + | 
|  | 318 | +## Breaking Change in Version 2.0.0 :boom: | 
|  | 319 | + | 
|  | 320 | +The only breaking change in this release is the renaming of the method `waitTillAllExecutingJobsAreSettled` to `waitForAllExecutingJobsToComplete` for improved readability. No other changes have been introduced. | 
|  | 321 | + | 
| 322 | 322 | ## License :scroll: | 
| 323 | 323 | 
 | 
| 324 | 324 | [MIT](LICENSE) | 
0 commit comments