Python: while True vs input() when using watchdog

I'm using python watchdog library to catch errors in logs of non-python CRM and I need to reduce the load as much as possible. Watchdog's Observer don't keep terminal attached so you need to make program running endlessly. So, I found two ways to do it:

def first_way(observer: PollingObserver):
    try:
        while True:
            time.sleep(100)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()


def second_way(observer: PollingObserver):
    input("Press <enter> to stop")
    observer.stop()

Both of them work. If I get it right, input() just pause program execution, so I think the second way is better... But it looks too easy to be true.

So I'd like to hear the pros and cons (or suggestion with alternative option)

I settled on input(), but I still have doubts

Using the Python Watchdog library to monitor log files for errors in a non-Python CRM system is a creative approach. Your focus on minimizing resource usage while ensuring the program runs continuously is crucial, especially in a production environment. Let's compare the two methods you've mentioned for keeping the program running:

First Way: Using time.sleep in a Loop

Pros:

• Simple and Effective: Keeps the program running indefinitely without requiring user interaction.
• Control over CPU Usage: By adjusting the sleep duration, you can control how often the loop wakes up, potentially reducing CPU usage.

Cons:

• Resource Usage: Even though time.sleep is efficient, the loop still consumes resources, albeit minimal, by periodically waking up.
• Less Responsive to Shutdown: Requires a keyboard interrupt (Ctrl+C) to stop, which might not be ideal in all deployment scenarios, especially when running in a background process or service where keyboard access isn't straightforward.

Second Way: Using input()

Pros:

• Very Low Resource Usage: The program is effectively paused waiting for user input, using very minimal resources.
• User-friendly Shutdown: Provides a simple, user-friendly way to stop the monitoring, especially suitable for interactive sessions or when running from a terminal.

Cons:

• Requires Active Terminal: The program relies on being run in an active terminal session where a user can input, which might not be suitable for all environments, especially in automated or background service deployments.
• Not Suitable for Unattended Execution: Since it requires user interaction to stop, it's not ideal for scenarios where the program needs to run unattended for long periods.

Alternative: Using a Signal Handler

If you're looking for a method that combines the benefits of both approaches (minimal resource usage and the ability to stop the program gracefully without requiring an active terminal session), consider using signal handling. This approach allows your program to catch system signals (like SIGINT for a keyboard interrupt or SIGTERM for a termination request) and stop gracefully.

import signal
import time

def signal_handler(signum, frame):
    print('Signal received, stopping observer.')
    observer.stop()
    observer.join()
    exit(0)

signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)

# Start your observer here
observer.start()

while True:
    time.sleep(100)

Pros:

• Graceful Shutdown: Allows the program to be stopped gracefully using system signals, which can be sent from other programs or scripts, not just the terminal.
• Flexible Deployment: Suitable for both interactive and background service deployments.

Cons:

• Slightly More Complex: Requires a bit more setup to handle signals properly.

In summary, the best approach depends on your specific deployment scenario and requirements. If you need the program to run in the background with minimal interaction, using a signal handler might be the most flexible and resource-efficient method.