[erlang-questions] : Subtle behaviour of Erlang scheduler
Tue May 29 12:34:41 CEST 2007
On Tue, May 29, 2007 at 12:11:38PM +0200, Ulf Wiger (TN/EAB) wrote:
> So, for the purposes of discussion, how would you feel
> about a change as the one I suggested - do simply disallow
> on-demand code loading for high priority processes?
> I would assume that it wouldn't hurt the existing code
> base, since there are so few processes running on
> high priority, and the designers have thought carefully
> about these aspects...
> ... or so I thought, until I implemented it.
> Below is a diff for the error_handler.erl.
> It simply checks if the process has priority
> high or max, and if so doesn't call on the code
> Interestingly, running with this patch causes
> global_group to crash at startup with an undef,
> when calling net_kernel. :-D
> I fixed that temporarily by moving the call to
> process_flag(priority, max) to the end of the init/1
> function in global_group.erl.
I perfectly understand what the point is :-) It seems too much easy to
break existing code, in a way or another, and it is quite normal in a
ten-years development. For this precise reason I thought that running
code server with high priority would somehow solve the problem, but I
agree with the fact that filesystem interaction could also be heavy and
So, just for the purpose of discussion, why don't think at "virtual"
synchronisation points for high priority procs ? I.e., if a high
priority task has not been interrupted for X reductions (beeing X a
relatively large integer), then goto do_schedule1 anyway, letting
other high priority process to run.... In this way, code server could
be put into high-prio queue, without problems for other high-prio
I think I'm going to test this solution, and let you know if it
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
More information about the erlang-questions