Hacker News Reader

Comment by brianwawok | Hacker News Reader

My server can easily fill all 96 running standard Python under gunicorn.

Even simpler:

  parallel -j96 'python -c "print('{}')"' ::: $(for i in {1..96};do echo $i;done)

gunicorn uses multiple processes

You can still share most of the memory if you load everything before the fork so why is having multiple processes a problem?

Ive found in practice that memory sharing doesn’t work as much as one would want, and multiple processes cost hundreds of megs (annoying!)

One operating system I have to deploy on (Windows) has neither fork() nor gunicorn.

Reference counting prevents that from working well. Very little sharing actually happens by default.

If the counts were kept somewhere else, they wouldn't pollute, or if you could turn off ref counts for everything allocated before the call to fork, then you would also be good.

The other option is you could allocate all the shared data off of the Python heap prior to the fork call.

Instagram have a system for making some objects immortal before the fork, but it’s not the default behaviour in Python. It’s also not easy to set up in some cases.

PEP683 finally landed in Python 3.12: https://peps.python.org/pep-0683/

It's been in Pyston for a while.

and if you use and async framework it's even more capable

Reply on news.ycombinator.com