[Python-Dev] startup time repeated? why not daemon

Gregory P. Smith greg at krypto.org
Thu Jul 20 20:49:31 EDT 2017


On Thu, Jul 20, 2017 at 10:56 AM Jim J. Jewett <jimjjewett at gmail.com> wrote:

> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>

This is one strategy that works under some situations, but not all.

There are downsides to daemons:
 * They only work on one machine.  New instances being launched in a cloud
(think kubernetes jobs, app engine workers, etc) cannot benefit.
 * A daemon that forks off new workers can lose the benefit of hash
randomization as tons of processes at once share the same seed. Mitigation
for this is possible by regularly relaunching new replacement daemons but
that complicates the already complicated.
 * Correctly launching and managing a daemon process is hard. Even once you
have done so, you now have a interprocess concurrency and synchronization
issues.

For example, in
> https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben
> Hoyt mentions that the Google Cloud SDK (CLI) team has found it "especially
> problematic for shell tab completion helpers, because every time you press
> tab the shell has to load your Python program"
>

I can imagine a daemon working well in this specific example.

Is it too hard to create a daemon server?
>

That is my take on it.

Is the communication and context switch slower than a new startup?
> Is the pattern just not well-enough advertised?
>

I have experienced good daemon processes. Bazel (a Java based build system)
uses that approach.

I can imagine Mercurial being able to do so as well but have no idea if
they've looked into it or not.

Daemons are by their nature an application specific thing.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170721/dbbe0179/attachment.html>


More information about the Python-Dev mailing list