olof
commented
8 years ago 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.
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?