Функциональщикам ЛОРа

Ненене. Чтобы переключить задачу, нужно ее сначала приостановить. Это можно сделаеть или постоянными проверками по всему коду (после чего расходы на сист. вызов покажутся мелочью), или системными способами (о которых я писал). Третьего способа я что-то не вижу.

Насколько помню, в Erlang'е перехватываются практически все действия потока. Вот пруф:

«Both processes and ports have a „reduction budget“ of 2000 reductions. Any operation in the system costs reductions. This includes function calls in loops, calling built-in-functions (BIFs), garbage collecting heaps of that process[n1], storing/reading from ETS, sending messages (The size of the recipients mailbox counts, large mailboxes are more expensive to send to).»

Т.е. есть только проверка на reductions < 2000.

... но везде.

Если интересно: http://jlouisramblings.blogspot.ru/2013/01/how-erlang-does-scheduling.html

Третьего способа я что-то не вижу

Эрланг интерпретирует байткод, поэтому он просто переключает задачу после интерпретации N инструкций.

Спасибо, занятно.

Эрланг интерпретирует байткод, поэтому он просто переключает задачу после интерпретации N инструкций.

Ну тут уже паказали, что нет. Но даже если - суть оставалась бы та же - постоянные проверки, «а не пора ли?». Хоть и подход с reductions в целом весьма нетребовательный.

можно не по всему коду, а в местах, где это безопасно, например при выделении памяти под объекты (так напр. это сделано в RTS haskell).

Ага. В то же время в плюсах на critical path часто обходятся без выделений памяти и имеют меньше проблем с производительностью. Тот же эрланг говорит про soft-realtime, но в realtime (в hard - вообще обязательно) за выделение памяти бьют по морде чайником.

для hard-realtime, есть yield. Но на haskell hard-realtime я бы писать не стал, если только с RTS от компилятора ajhc.

Это понятно. Но вытеснение в hard real-time тоже есть.

в хард реалтайме у тебя malloc не будет.

Будет. Особый уличный. Для вызова перед стартом задачи, чтобы раз и навсегда выделить память.

по lightweight threads и realtime scheduling я инфы сходу найти не смог, я ведь так понимаю, что разговор про это. Просто вытестение процессов ядром при этом остается.

Это уже не совсем маллок, это выделение статического буфера перед работой, а там уже крутись как хочешь, fortran-style :)

Это уже не совсем маллок, это выделение статического буфера перед работой, а там уже крутись как хочешь, fortran-style :)

Я что-то не припомню, чтобы для итерации rt-задачи нужно было работать с кучей, т.е. иметь не заранее четко определенный объем данных.

Ну hard rt начинается с соответствующей ОС и правильного железа, потому в контексте чистого линукса оно вообще не бывает. А так - rt-thread ОС + rt user-thread'ы с соотв. планированием = success.

ну просто вроде тред про функциональщину с под-тредом про erlang и огранизацию легких процессов, поэтому я надеюсь, что ОС и железо тяжеловесные user-threads не попадают в рамки обсуждения.

в хард реалтайме у тебя malloc не будет.
Dark_SavanT

Конечно же будет! Но - один раз при старте :)