<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 6, 2014 at 7:27 PM, Camille Troillard <span dir="ltr"><<a href="mailto:lists@tuli.pe" target="_blank">lists@tuli.pe</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ideally, I thought the design could be as follows: a gen_server (serial_endpoint) whose lifetime would be the same as the serial device’s connection is under supervision. If the serial_endpoint fails to start, then we try again a second later and so on. Likewise, if the connection is lost because the device is unplugged, the serial_endpoint dies, and we try again to start it a second later.</blockquote>

</div><br>Note that supervision and restarts are normally for unforseen errornous behaviour in applications. In your model, I would assume it is normal to have devices disconnecting and reconnecting. After all, there is a connector for the serial device and people might be yanking out the device now and then. This suggests that the disconnect is not an unforseen error, but rather a valid situation. This warrants handling it as part of the normal application flow and not as part of supervision fault handling.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I tend to keep supervision and crashes as devices for handling things that you don't expect the application to do. Sometimes you *can* model things with processes marked as 'temporary' in the supervision trees and you don't care if such a process goes away since it is the normal behaviour of the application.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">First of all, I would consider if device monitoring and device handling has to live in the same process. They seem to be possible to decouple. So one process listens on device events and starts a handling process accordingly. If the device is disconnected, the handling process can be killed by the monitoring process. It also means that the cleanup in the event of a disconnected device is left to the monitor and not to the handler. Pursuing this idea has the advantage that you decouple device presence from the question of device protocol handling, making it pluggable, flexible and simpler to implement.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">As for a supervision tree:</div><div class="gmail_extra"><br></div><div class="gmail_extra">main_sup - one_for_all (perhaps one_for_rest)</div><div class="gmail_extra">

    monitor - gen_server, permanent</div><div class="gmail_extra">    device_handler - gen_server, transient, started dynamically in the tree when device is present.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

The monitor should always run. It periodically checks connectivity on the serial port. When it detects a device attached, it spawns the device_handler. The transient rule makes sure that the device handler can stop in a normal fashion, should the device be gracefully disconnected.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">How does this system crash? If the monitor dies *unexpectedly*, we rip the device handler as well. If the device_handler dies, we restart the monitor as well. When the system restarts it will attempt to reconstruct a good state. You can play around with one_for_rest as a strategy if you want the device handler to be restartable without killing the monitor.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">This might not be perfect, but it is a start of a model. Feel free to ask more questions.</div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br>J.
</div></div>