[erlang-questions] Dependencies, included applications and supervision

[Loïc Hoguin]

On 06/25/2014 11:03 PM, Jay Nelson wrote:
>
> On Jun 25, 2014, at 1:50 PM, Loïc Hoguin <essen@REDACTED> wrote:
>
>> On 06/25/2014 10:42 PM, Jay Nelson wrote:
>>> Why does crypto code always do this?
>>
>> Not sure what you mean? crypto is a library it doesn't need to be started.
>
> I misspoke. Take a look at pg2:ensure_started. I don’t want to write code like that to make
> sure that an application is running.

I'm not sure how that's related. pg2 isn't an application. It's not 
written this way for handling restarts, because as you can see it's 
marked as permanent, and if kernel_safe_sup dies the Erlang node is 
killed anyway. The VM doesn't start pg2 by default, which is probably 
why this function is there.

It's ugly, but it's completely unrelated to the topic at hand.

>>> What if your application goes down but doesn’t take the VM with it?
>>
>> If you configure the VM to do that you probably have good reasons and *don't* want it to restart. For example to debug things out.
>>
>> Configuring the VM to crash, and it failing to do so, has about the same chances of happening as your supervisor not restarting the included_application.
>
> I thought it was apparent from the context, but I meant, what if your required
> essential dependency of an application goes down and you didn’t configure
> it as a permanent application (because it’s a hammer and you want something
> less than the entire node to go down and still recover). The fact that you have
> two choices: kill the node or ignore, is limiting when dealing with complex
> dependency constraints. Especially in continuous realtime services where the
> loss of a database connection is an essential dependency but not sufficient to
> immediately turn off all access to the node.

But why would you make the application crash if you need it to stay 
alive? If your DB driver application crashes because the DB is gone, 
something is *very* wrong with your DB driver application. I personally 
would stay the hell away from it.

Regardless, if the DB driver application crashes because the DB is gone, 
I'm not sure how including it in your other application is any better, 
as it'll quickly kill it too if it starts doing a restart-crash-loop.

>>> If there is a dependency, you must ensure that the required application
>>> is started, not just when you start your application, but at any time later
>>> after which it may have subsequently failed.
>>
>> Only if you want to restart it, which you don’t.
>
> I wasn’t aware that you were familiar with my code. In my case I do want
> to restart. But you as library or reusable application developer can’t possibly
> know what I will use it for in the future. And arbitrary restrictions on reuse
> shouldn’t be built in unless there are good reasons for doing so.

Don't think anyone here spoke about restricting reuse.

-- 
Loïc Hoguin
http://ninenines.eu