Kept-alive Worker Server
The example at /docs/src/examples/kept-alive-worker-server runs a Deno server script as a continuously monitored and restarted process using a worker. The process has logging configurations to write logs to separate files.
- pup.jsonc - Pup configuration, sets up
server.jsto be kept alive forever and restarts with a 10 seconds delay.
- server.js - Worker server script that runs an HTTP server. It sends log messages and exit signals through the logger facility.
Start example by running
pup run if pup is installed, or something like
deno run -A ../../../pup.ts run if not.
In this example, we are running the server script as a worker instead of a separate process. Using worker mode has some advantages over process mode:
Performance: Workers run in the same process as the main script, allowing for faster communication between the main thread and the worker. This can lead to performance improvements, as it reduces the overhead of inter-process communication (IPC).
Resource Management: Workers share the same resources as the main process, which can be more efficient in terms of memory usage and CPU time. This is particularly beneficial for applications that require frequent communication between the main thread and the worker, as they can leverage shared memory and avoid the cost of serialization and deserialization.
Simplified Error Handling: In worker mode, errors can be more easily caught and handled within the same context. This can simplify error handling, especially when compared to managing errors across multiple processes.
In summary, worker mode can be a more efficient and easier-to-manage alternative to process mode in certain scenarios, but it's essential to carefully consider the specific requirements and constraints of your application when making this choice.