[erlang-questions] : Subtle behaviour of Erlang scheduler

[Ulf Wiger]

I agree. We've had a design rule for years saying that the
only place where 'high' priority is allowed is in "dispatch"
processes, such as middle men etc., which don't create
any work, but simply touch a job and pass it on. Putting
them on high priority is merely an attempt at minimizing
the per-call latency. I have no empirical evidence that it
actually does so on average.

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?

We always run our systems with embedded code loading,
so if the module is not present, the call simply fails.

The documentation could state clearly that high priority
and on-demand code loading from disk simply do not play
well together. Luckily there's at least one remedy.

BR,
Ulf W


2007/5/28, Kenneth Lundin <kenneth.lundin@REDACTED>:
>
> Hi,
>
>
> We will add a better description about what the priority levels means and
> how to use them. We will also add to the documentation that the use
> of different priority levels than 'normal' is highly questionable.
> The priority levels have been around for 10 years or more and the use
> is to our knowledge VERY VERY RARE.
>
> For all code in the Erlang/OTP distribution there are only
> 11 modules where process_flag(priority,Prio) is explicitly used.
> Of these I would say that a handful of them can be questioned if they
> really
> are necessary.
>
> Summary:
>
> It is important that we make clear in the documentation how priorities
> work and
> that you have little or no reason to use them.
>
> I hope we can close this discussion now.
>
> /Regards Kenneth (Erlang/OTP team at Ericsson)
>
> On 5/28/07, David Hopwood <david.hopwood@REDACTED>
> wrote:
> > Rickard Green wrote:
> > > Raimo Niskanen wrote:
> > >
> > >> I guess the solution for the problem at hand would be to make
> > >> sure all code for the high priority processes are loaded
> > >> 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).
> > >
> > > We reason like this: Priority levels other than normal, should
> normally
> > > not be used. When other priority levels are used, they have to be used
> > > with extreme care. The programmer have to take things like this into
> > > account.
> >
> > I'm surprised at this conclusion. Most code should be able to consider
> the
> > existence of the code server process as an implementation detail.
> Certainly
> > the fact that this process runs at normal priority is an implementation
> > detail. What other facts about the Erlang/OTP implementation might we
> need
> > to know in order to be able to reliably run code at high priority?
> >
> > --
> > David Hopwood <david.hopwood@REDACTED>
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070528/96b34b38/attachment.htm>