<br>I agree. We've had a design rule for years saying that the <br>only place where 'high' priority is allowed is in "dispatch"<br>processes, such as middle men etc., which don't create<br>any work, but simply touch a job and pass it on. Putting
<br>them on high priority is merely an attempt at minimizing <br>the per-call latency. I have no empirical evidence that it<br>actually does so on average.<br><br>If the code server were to be run at high priority, I don't
<br>really see what's supposed to happen when it goes to the<br>file system to fetch the file; the file system can be arbitrarily<br>slow (try ClearCase, for example). Should the file system read<br>also run at high (blocking) priority?
<br><br>We always run our systems with embedded code loading,<br>so if the module is not present, the call simply fails.<br><br>The documentation could state clearly that high priority<br>and on-demand code loading from disk simply do not play
<br>well together. Luckily there's at least one remedy.<br><br>BR,<br>Ulf W<br><br><br><div><span class="gmail_quote">2007/5/28, Kenneth Lundin <<a href="mailto:firstname.lastname@example.org">email@example.com</a>
>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br><br><br>We will add a better description about what the priority levels means and
<br>how to use them. We will also add to the documentation that the use<br>of different priority levels than 'normal' is highly questionable.<br>The priority levels have been around for 10 years or more and the use
<br>is to our knowledge VERY VERY RARE.<br><br>For all code in the Erlang/OTP distribution there are only<br>11 modules where process_flag(priority,Prio) is explicitly used.<br>Of these I would say that a handful of them can be questioned if they really
<br>are necessary.<br><br>Summary:<br><br>It is important that we make clear in the documentation how priorities work and<br>that you have little or no reason to use them.<br><br>I hope we can close this discussion now.<br>
<br>/Regards Kenneth (Erlang/OTP team at Ericsson)<br><br>On 5/28/07, David Hopwood <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<br>> Rickard Green wrote:
<br>> > Raimo Niskanen wrote:<br>> ><br>> >> I guess the solution for the problem at hand would be to make<br>> >> sure all code for the high priority processes are loaded<br>> >> before they are started,
e.g by calling Module:module_info/0<br>> >> on them. That trick is done by the code server itself<br>> >> to ensure it can start without a running code server.<br>> ><br>> > Yes, this is the way to do it.
<br>> ><br>> > We had a discussion about these things this morning at OTP, and we have<br>> > decided to leave things as they are (no propagation of prios, and leave<br>> > code server on prio normal).
<br>> ><br>> > We reason like this: Priority levels other than normal, should normally<br>> > not be used. When other priority levels are used, they have to be used<br>> > with extreme care. The programmer have to take things like this into
<br>> > account.<br>><br>> I'm surprised at this conclusion. Most code should be able to consider the<br>> existence of the code server process as an implementation detail. Certainly<br>> the fact that this process runs at normal priority is an implementation
<br>> detail. What other facts about the Erlang/OTP implementation might we need<br>> to know in order to be able to reliably run code at high priority?<br>><br>> --<br>> David Hopwood <<a href="mailto:firstname.lastname@example.org">
email@example.com</a>><br>><br>> _______________________________________________<br>> erlang-questions mailing list<br>> <a href="mailto:firstname.lastname@example.org">email@example.com
</a><br>> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>><br>_______________________________________________<br>erlang-questions mailing list
<br><a href="mailto:firstname.lastname@example.org">email@example.com</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>