<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff 
size=2></FONT> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2>Hi, there is a reason why there is no terminate function in a supervisor. 
For the supervisor recovery schem to be correct (seen from the over all systems 
perpective) supervisors *must* be free of errors. That is why the programmer is 
not given the chance of writing code that shall be executed in its 
context.</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2>(In the beginning, before someone destroyed it :-) the supervisor was 
written completely in its own module. Where there actually was a big part of 
copied code from the gen_server and general gen code. The reason for copying the 
code was of course to make sure that not something got "improved" when some 
other feature in OTP was inteed improved).</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2>But to your question, no there is no regular way of asking about the 
current intensity. But once again as I hinted in the previous mail. There is 
nothing that prevents you from adjusting the sliding window to make the 
supervisor never escalate restarts.</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2>Best Regards</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2>Lennart</FONT></SPAN></DIV>
<DIV><SPAN class=382223707-23032009><FONT face="Courier New" color=#0000ff 
size=2></FONT></SPAN> </DIV><!-- Converted from text/plain format -->
<P><FONT face="Courier New"><FONT 
size=2>-------------------------------------------------------------------------------<BR>Lennart 
Öhman                    
phone: +46 8 587 623 27<BR>Sjöland & Thyselius Telecom AB   cell : 
+46 70 552 6735<BR>Hälsingegatan 43, 10th floor     
fax  : +46 8 667 8230<BR>SE-113 31 STOCKHOLM, 
SWEDEN      email: lennart.ohman@st.se</FONT> 
</FONT></P>
<DIV><FONT face="Courier New"></FONT> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> erlang-questions-bounces@erlang.org 
[mailto:erlang-questions-bounces@erlang.org] <B>On Behalf Of </B>steve 
ellis<BR><B>Sent:</B> den 22 mars 2009 15:58<BR><B>To:</B> Mihai Balea; 
erlang-questions@erlang.org<BR><B>Subject:</B> Re: [erlang-questions] to 
supervise or not to supervise<BR></FONT><BR></DIV>
<DIV></DIV>Thanks Lennart and Mihai! Very helpful information. Lennart it's good 
to know about the intent behind supervisor's orignial design.<BR><BR>I like 
Mihai's suggestion of having one supervisor supervise each process. This would 
get us most of the way there and it would be easy to implement.<BR><BR>But is 
there any way in OTP to see when a supervisor reaches its max restarts? I know 
this is logged by the sasl error logger. But how would I trap/detect this event 
in my code to do something with it?<BR><BR>It doesn't look like supervisor has a 
function like gen_server's handy terminate/2.<BR><BR>Maybe it would make more 
sense in our case to have one gen_server process monitor a child gen_server 
process. The child could call a function in the parent when it terminates. This 
way we'd have access to the terminate function of the monitoring/supervising 
gen_server. The problem with this though is that we'd have to implement our own 
restart strategy behavior, which is what is so great about 
supervisor.<BR><BR>This might be related to something more general that I've 
been wondering about (which I should post as a question in a new thread). How to 
tap into the sasl error logger so my system can do stuff with those events. For 
example I'd like to send these events to another machine via 
tcp.<BR><BR>Thanks!<BR><BR>Steve<BR><BR>
<DIV class=gmail_quote>On Fri, Mar 20, 2009 at 5:29 PM, Mihai Balea <SPAN 
dir=ltr><<A href="mailto:mihai@hates.ms">mihai@hates.ms</A>></SPAN> 
wrote:<BR>
<BLOCKQUOTE class=gmail_quote 
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
  <DIV>
  <DIV></DIV>
  <DIV class=h5><BR>On Mar 20, 2009, at 3:42 PM, steve ellis wrote:<BR><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">New 
    to supervision trees and trying to figure out when to use them (and when not 
    to)...<BR><BR>I have bunch of spawned processes created through spawn_link. 
    Want these processes to say running indefinitely. If one exits in an error 
    state, we want to restart it N times. After N, we want to error log it, and 
    stop trying to restart it. Perfect job for a one_to_one supervisor 
    right?<BR><BR>Well sort of. The problem is that when the max restarts for 
    the error process is reached, the supervisor terminates all its children and 
    itself. Ouch! (At least in our case). We'd rather that the supervisor just 
    keep supervising all the children that are ok and not swallow everything 
    up.<BR><BR>The Design Principles appear to be saying that swallowing 
    everything up is what supervisors are supposed to do when max restarts is 
    reached which leaves me a little puzzled. Why would you want to kill the 
    supervisor just because a child process is causing trouble? Seems a little 
    harsh.<BR><BR>Is this a case of me thinking supervisors are good for too 
    many things? Is it that our case is better handled by simply spawning these 
    processes and trapping exits on them, and restarting/error logging in the 
    trap exit?<BR></BLOCKQUOTE><BR></DIV></DIV>As far as I know, the standard 
  supervisor cannot behave the way you want it to.<BR><BR>So, at least until 
  this type of behavior is added to the standard supervisor, you can work around 
  it with double layers of supervision.  Basically have one dedicated 
  supervisor for each process you want to supervise and, in turn, each dedicated 
  supervisor is set up as a transient child to one big supervisor.<BR><FONT 
  color=#888888><BR>Mihai<BR><BR></FONT></BLOCKQUOTE></DIV><BR></BODY></HTML>