[erlang-questions] Subtle behaviour of Erlang scheduler
Sat May 26 01:52:20 CEST 2007
Yes you found an interesting bug.
after 1000 -> ok
and it works! (at least for me, but with in GDB the code may work
The definition of timer:sleep is however:
after T -> ok
which looks very much like the code above ;-)
I think OTP team will have some debugging sessions, I tried a bit but
could not find it..... yet :-)
On 25 maj 2007, at 18.37, KatolaZ wrote:
> On Fri, May 25, 2007 at 09:26:49AM -0700, Bob Ippolito wrote:
>> Unless "high" means "only schedule out at synchronization points".
>> It's not documented as such, but it sure could be given the behavior.
>> I guess the real question is why they think they need to use it in
>> first place.
> No, bob, unfortunately thing are not so. Even if high would mean
> "only schedule at synchronisation points", that does not explain
> why that piece of code DOES NOT work if executed as the first piece of
> code in the erl shell, while it DOES work when executed after the
> other version (the one with explicit timer:sleep) has been executed.
> According to us, it seems to be a serious flaw in priority
> management. In a couple of words: "a bug, not a feature", even if we
> were not able to discover where the flaw actually is, neither looking
> at the scheduler source code (erl_process.c).... :-)
> The problem is not if anybody would eventually need to use a high
> priority process as we do in that piece of code. The question is why
> using it in that way does not produce predictable effects in case
> anybody would do, as expected from a reliable and predictable
> scheduler.... :-)
> [ 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 ]
> erlang-questions mailing list
More information about the erlang-questions