embedding in a Windows service written in Python

[vashek]

Hi there. I'm making a program that will generally run as a Windows service (using cx-Freeze for the .exe bulding) and needs to serve a simple, low-traffic web app using an embedded web server for simplicity of deployment. I've stumbled upon Granian so I thought I'd give it a try this time around, not really having settled on a Python web server that I really like using.

I do have it working and don't see any obvious problems so far, but I did have to work around a few things and I wonder if I'm stretching the use case beyond what was intended, or if these are just things that haven't yet been thought of / implemented.

First off, the README only documents running Granian as a standalone command-line program, whereas I needed to embed it in mine. This was simple enough to solve, I just do (web_server := Granian(something)).serve() in a thread, and then self.web_server.exit_event.set() when stopping the service. No problem, just not documented.

Next, because this runs in a non-main thread, I got a ValueError: signal only works in main thread of the main interpreter in Granian.startup(), so I set Granian.SIGNALS = set().

Then I had to figure out logging to 1) make sure it works properly with the multiple processes, and 2) avoid re-inventing the logging configuration that my service already has, and what I did was I:

1. replaced configure_logging with a no-op in the parent process (granian.server.configure_logging = granian.log.configure_logging = lambda *args, **kwargs: None) so that it doesn't touch my existing logging configuration,
2. for the spawned process(es), passed a log_dictconfig that uses logging.handlers.QueueHandler(log_queue) where log_queue is a multiprocessing.Queue, and then I have a separate thread in the parent process that reads the queue and does the actual logging (basically the code from https://docs.python.org/3/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes),
3. for log_level, I'm passing LogLevels[logging.getLevelName(logging.root.level).lower()] (to just preserve the already configured log level), which seems unnecessarily complicated.

Finally and perhaps most importantly (and most hackishly), the spawned process needs to get some configuration data from the parent process, which on Windows doesn't work via a global variable (https://docs.python.org/3/library/multiprocessing.html#the-spawn-and-forkserver-start-methods). Unfortunately Granian doesn't seem to provide a way to pass a value into the spawned process that I could then access from my web app, so what I did was this:

class PatchedGranian(Granian):
    def _spawn_proc(self, *args: Any, **kwargs: Any) -> multiprocessing.Process:
        proc = super()._spawn_proc(*args, **kwargs)
        proc.GLOBAL_CONFIG = GLOBAL_CONFIG  # type: ignore[attr-defined]
        return proc

And then in my web app, I call ensure_config() which is:

def ensure_config() -> GlobalConfigAndState:
    if hasattr(multiprocessing.current_process(), "GLOBAL_CONFIG"):
        logging.debug("Got config from parent process")
        GLOBAL_CONFIG.__dict__.update(
            multiprocessing.current_process().GLOBAL_CONFIG.__dict__)  # type: ignore[attr-defined]
    return GLOBAL_CONFIG

(where GLOBAL_CONFIG is just a trivial object with some data attributes).

For the sake of completeness, my main script also needs to include calling multiprocessing.freeze_support() like this:

if __name__ == '__main__':
    freeze_support()
    main()

That's it, everything seems to work this way. But I'm wondering whether there was a better way (in particular considering I don't have experience with multiprocessing)?

Would you consider adding supported solutions to these things to Granian? I'd be happy to offer some PRs.

[gi0baro]

Hi @vashek, thank you for the well-written details about your use case.

I'll start with a couple of considerations:

• the vast majority of features you need for your use-case are missing just because no use-case like this emerged in the past; I don't see any particular stretching of the scope of the project in supporting embedding strategies
• the only alternative approach I can think of compared to what you did would be to use a subprocess instead of a thread to start Granian: in such way you won't need to tamper with signals. Everything else seems pretty straight-forward to me.

Now, regarding everything else:

• we can for sure add to the README documentation on running Granian via its Python interfaces
• the logging configuration implementation is almost 99% dependant on how pyo3-log works. The only way I see to simplify your use-case would be to add some booleans in the Granian class or to make a method inside the Granian class that configures logging so you can override it to do nothing, and probably have a default for the logging level that gets the current logging module level
• I don't see anything wrong into subclassing the Granian class to change the spawning mechanism for some specific needs: introducing an interface like on_process_spawn would probably require the same amount of code you wrote, so I don't really see the advantage there..

In conclusion: you are super-welcome to open PRs! I'm quite busy/AFK during this time of the year, but I'll make my best to comment/review them as soon as I can :)

[ahirner]

For the sake of completeness, my main script also needs to include calling multiprocessing.freeze_support() like this:

I'm familiar with this requirement for (frozen) windows deployments. Out of curiosity: you didn't run or try to run multiple workers with a custom spawn_target @vashek ?

Ref:

granian/granian/server.py

Lines 309 to 317 in ee9b0dd

	if not spawn_target:
	spawn_target = default_spawners[self.interface]
	if sys.platform == 'win32' and self.workers > 1:
	self.workers = 1
	logger.warn(
	"Due to a bug in Windows unblocking socket implementation "
	"granian can't support multiple workers on this platform. "
	"Number of workers will now fallback to 1."
	)