RFC: Always run workers in a subprocess.

[ahopkins]

Proposal: Always run workers in a subprocess.

Currently, when in PRODUCTION mode with workers=1, the server runs in the main process. This can lead to a discrepancy since the server(s) will be in a subprocess if:

• there are multiple workers
• auto_reload is enabled

We can create a more consistent experience if it will always be in a subprocess.

[Tronic]

I considered this in the Trio fork I worked on, and made workers=0 mean that it runs in the main process, while workers=1 spawns a subprocess for the single worker. There are good reasons to run a server without any subprocesses, especially in debug mode, but also in production, so running without subprocesses should remain an option at least.

If this causes trouble in multi-serve or other development, the main Sanic.serve() could become always subprocess-using if there was a await Sanic.serve_async() style lower level API for those who need strictly single process (or ability to run other things on the same asyncio loop, possibly deprecating the always discouraged create server method of doing that, if it can be better supported with a new API).

[ahopkins]

You make a good point. I think the core of what I was going after is the "gotcha" of a newcomer. This can easily be added with the new Sanic.serve style once that is merged.

I am currently leaning towards workers=0 since that means no additional API, and no competing config values (example workers=2, single_process=True.

He big change is really documentation then.

[Tronic]

I don't remember the exact state of CLI flags in 22.3, but it would probably then make sense to have --debug imply workers=0 by default, while --dev sticks to workers=1 to avoid surprises when switching to production mode. I recall PyCharm also had some particular issue with subprocesses, and pytest/coverage is certainly a bit flaky with them.

[ahopkins]

That I think would cause more confusion. Currently:

--dev == --debug + --auto_reload 

For debug mode to then change one thing would be non-obvious.

[Tronic]

I am leaning more and more towards not spawning any workers unless using --fast. But probably some other developers/users should weigh in. I always run with multiple workers anyway, and have little more to add to this.

[ahopkins]

Okay, so I have put some more thoughts and effort into this. I think that we should perform the following:

• Sanic.serve (and therefore also the sanic CLI) will always run a main process, with and use multiprocessing for starting one or more workers in a subprocess
• Doing this will allow us to also open up an API for passing things like a multiprocessing.Queue among multiple workers (on the same interpreter of course)
• Sanic.serve_single will be for running serve in a single process
• Autoreload needs an overhaul as well - rather than running the server with subprocess.Popen, I think we should also do this with multiprocessing. This means autoreload would not be possible from serve_single
• Sanic.prepare should get a new flag so that you can prepare multiple applications to run separately in their own processes instead of sharing (this will be helpful in the HTTP/3 solution)

[Tronic]

All that sounds good. Any chance of having a pathway to fixing Windows (or MacOS) where forking is not possible?

[ahopkins]

All that sounds good. Any chance of having a pathway to fixing Windows (or MacOS) where forking is not possible?

Yes, I think this is doable. I have had it working, but not done a full test yet to make sure it does not cause a regression somewhere else.