Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lifetime of a worker process #13

Open
orzen opened this issue Aug 4, 2016 · 1 comment
Open

Lifetime of a worker process #13

orzen opened this issue Aug 4, 2016 · 1 comment

Comments

@orzen
Copy link
Owner

orzen commented Aug 4, 2016

An OTP application contains a supervision tree design.

A supervision tree design contains a supervisor process that keeps track of a server process and another supervisor process, this supervisor is referred to, as the super supervisor (visualized below). The second supervisor will keep track of workers. The supervisor will spawn and terminate workers based on internal API calls to the server process.

o super supervisor
|- server
|- supervisor
| |- worker X
| |- worker Y

In cases where there are multiple processes depending on a certain worker's existence. It becomes relevant to have a life span that is implicitly controlled by these processes. This could be handled in multiple ways and therefore this discussion. An example where it is relevant within ertorrent is the handling of tracker worker processes. Multiple torrents might want to communicate with the same tracker, the tracker worker process can therefore not get killed off when one of the torrent processes consider itself to finished with the communication.

Two suggestions is reference counting and timeout.

A passive approach is timeout. When a process is needed it is spawned and it live as long as the depending processes is feeding it. When fed, the process will reset its timer. The risks with this approach is inefficiency and it's considered a fragile design. The fragile part is that the process risk to terminate when another process is about to feed it.

In my opinion the reference counting is more robust and won't leave processes alive and awaiting termination and therefore more efficient.

Thoughts and opinions?

@olof
Copy link
Collaborator

olof commented Aug 5, 2016

Nice writeup... Some comments and questions:

  • Why do we need to use a tracker worker at all? HTTP pipe lining? Rate limiting? What's the benefit over letting the torrent announce itself?
  • If we go with the timeout thing, I don't think it's an issue that a tracker worker can have died, if we make sure that they are started on demand. With ref counting, we need to think carefully about how to avoid leaks.

@olof olof changed the title Discussion: Lifetime of a worker process Lifetime of a worker process Aug 5, 2016
@olof olof assigned olof and orzen and unassigned olof Aug 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants