[erlang-questions] Subtle behaviour of Erlang scheduler

[Tony Rogvall]

Wow!

Before my post was even on the list, you cracked it. Good catch! You  
are mister runtime system ;-)
And order is restored !

/Tony



On 25 maj 2007, at 23.48, Rickard Green wrote:

> This behavior is due to the fact that the code server runs on priority
> normal.
>
> If the code for the timer module hasn't been loaded before you start
> your program, proc1 will block forever in the call to timer:sleep
> waiting for the code server to load the code for the timer module.  
> Since
> the code server runs on normal prio, it wont be scheduled until the  
> high
> prio run-queue is empty.
>
> Try l(timer) before running you program, and everything will work as
> expected.
>
> This behavior is in my opinion unfortunate, and we will probably
> increase the priority level of the code server some time in the  
> future.
>
> BR,
> Rickard Green, Erlang/OTP, Ericsson AB.
>
>
> KatolaZ wrote:
>> Dear Erlang Gurus,
>>
>> we have tested the priority system of the processes and we are
>> experiencing a very strange behaviour.
>>
>> Take a look at the simple code attached: if you run "test:test()"  
>> from
>> the shell, the system hangs and "proc2" never ends blocking also
>> "proc1" and the shell. We think that this is due to the fact that
>> "proc2" hasn't any synchronization point, i.e. send or receive
>> messages, etc. In any case, this is quite strange since also "proc1"
>> has priority set to "high", so sooner or later, it should be selected
>> to be scheduled.
>>
>> Now kill the shell (with CTRL+C, you don't have any other option!),
>> uncomment the "timer:sleep(1)" statement in proc2, recompile and
>> everything seems to work fine: "proc2" and "proc3" exit, and the  
>> value
>> reached by the counter proves that proc2 really runs with a higher
>> priority than proc3.
>>
>> Well, now, don't exit from the shell, comment again the
>> "timer:sleep(1)" line, compile the code with "c(test)", and run it
>> again. Well, now it works!!! But if you (once again) exit the shell,
>> run "erl" again and launch "test:test()" once more.... it blocks!!!
>>
>> What's behind this strange behaviour? An undocumented feature? A bug
>> in scheduler initialization? Too many beers before sitting down for
>> coding :-))) ???
>>
>> All the best,
>> --Enzo and Corrado
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions