Bugs in singleton and signal handling for csclient

[ftsfranklin]

csclient registers a signal handler for SIGTERM, which cleans up EventingCSClient and then exits with 0.

sdk-samples/app_template_csclient/csclient.py

Lines 598 to 608 in 5f4ce85

	def clean_up_reg(signal, frame):
	"""
	When 'cppython remote_port_forward.py' gets a SIGTERM, config_store_receiver.py doesn't
	clean up registrations. Even if it did, the comm module can't rely on an external service
	to clean up.
	"""
	EventingCSClient('CSClient').stop()
	sys.exit(0)
	signal.signal(signal.SIGTERM, clean_up_reg)

In reality, it creates a NEW EventingCSClient (with a new registry) and calls stop on it. If there is already a singleton with the exact class EventingCSClient, it will use that one instead. If there is a subclass of EventingCSClient, it will not use that one, because of how the singleton lookup works.

There is also a misunderstanding of how __init__ works. The __init__ function is called on the result of __new__ even if the object was already initialized. That means the signal handler will replace the registry before it cleans it up.

Sample code demonstrating the double init:

class A:
    _instances = {}
    def __new__(cls, *na, **kwna):
        """ Singleton factory (with subclassing support) """
        try: instance = cls._instances[cls]
        except KeyError: instance = cls._instances[cls] = super().__new__(cls)
        return instance

class B(A):
    def __init__(self, value):
        self.value = value
        print('init', value)

b0 = B('first')          # init first
b1 = B('second')         # init second
print(f"{b0 is b1 = }")  # b0 is b1 = True
print(f"{b0.value = }")  # b0.value = 'second'

If there is no object with exact class EventingCSClient, the stop() call will crash when it tries to access self.event_sock, because that is only created by the start call, not for a fresh new object.

What is the intent of this signal handler? It refers to "remote_port_forward.py" and "config_store_receiver.py", neither of which are in this repo.

Turning a SIGTERM into a SystemExit(0) changes the behavior of applications. For example, non-daemon threads can ignore SystemExit but not SIGTERM. Is that intentional?