<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

really see what's supposed to happen when it goes to the file system to fetch the file; the file system can be arbitrarily slow (try ClearCase, for example). Should the file system read 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:kenneth.lundin@gmail.com">kenneth.lundin@gmail.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:david.hopwood@industrial-designers.co.uk">david.hopwood@industrial-designers.co.uk</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 > >> on them. That trick is done by the code server itself > >> to ensure it can start without a running code server. > > > > Yes, this is the way to do it.

> > > > We had a discussion about these things this morning at OTP, and we have > > decided to leave things as they are (no propagation of prios, and leave > > 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:david.hopwood@industrial-designers.co.uk">

david.hopwood@industrial-designers.co.uk</a>><br>><br>> _______________________________________________<br>> erlang-questions mailing list<br>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org

</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:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>

</div><br>