[erlang-questions] : Subtle behaviour of Erlang scheduler

[KatolaZ]

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
> server.
> 
> 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.

:-DDD

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
slow...

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
procs...

I think I'm going to test this solution, and let you know if it
works...

HND

Enzo

-- 
[ 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 ]