Впечатляющая внимательность к пользователям. Любопытно, есть примеры проектов, в которых BuguRTOS используется? И что в планах - как именно планруется покорить мир и куда двигаться вообще?

см. OSMOCOMM

Во-первых Osmocom, а во-вторых лучше не смотри - непосредственно к Nuttx там имеет отношение только пара патчей для лучшей портабельности, сам проект совсем про другое.

Кстати, обнови заголовок репозитария на github на что-нибудь приличное вместо exported from googlecode.

C++ 17.2% Objective-C 2.5%

Гитхаб старается причинить тебе бугурт, школьник!

Я знал, что её вспомнят. Но там другая крайность - всё на ассемблере.

    Ассемблер FASM
    Ассемблер NASM
    Ассемблер MASM
    Среды Visual C++ 6, C++ из Visual Studio .NET/2005
    Компиляторы GCC, G++
    Компилятор Borland C++
    Компилятор Tiny C
    Компилятор Pascal Pro 

Использование различных компиляторов в КолибриОС: http://diamond.kolibrios.org/hll/hll.htm

Зачем тогда их перенесли в новую мажорную версию?

Библиотека native сделана для переноса софта с старых версий с сохранением обратной совместимости (по возможности).

Соответственно, тяжкое наследие переносилось вместе с недостатками.

Некоторые имена имеют префикс bgtr_, а некоторые — не имеют.

В старом API префикса не было.

На самом деле задачи есть:

1. Код в автоматном стиле занимает больше памяти из-за свичей на каждом шагу, в том числе вложенных, и жрет процессорное время на постоянную проверку условий, которые, как правило, не выполняются.

2. Некоторые библиотеки для тех же AVR писаны в императивном стиле с циклами ожидания...

Особенно показательны жалобы ардуинщиков на DS18B20, типа сильно тормозит...

Чтобы можно было использовать такие библиотеки нужна труЪ многозадачность.

3. Императивный код проще писать, можно использовать труд менее квалифицированных прогираммистов...

А зачем покорять мир? Я же не пинки и брейн!

Кстати, обнови заголовок репозитария на github на что-нибудь приличное вместо exported from googlecode.

Doen!

Для нее хотя бы fort есть?

Зачем?

Я сторонник большого количества маленьких независимых библиотек, а не монолитных комбайнов!

Вопрос

И почему же вы сторонник этого заявления?

тяжкое наследие переносилось вместе с недостатками
В старом API префикса не было.

Но ведь вышла новая мажорная версия! Если бы именование в ней было приведено к более логичному виду, то для новых пользователей BuguRTOS смотрелся бы чуточку более привлекательно. Есть какая-нибудь политика, определяющая, как долго «тяжкое наследие» будет отравлять будущие релизы?

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

Алсо, глупый вопрос, ты вот эту статью прочитал? — http://dept-info.labri.fr/~denis/Enseignement/2008-IR/Articles/01-futex.pdf

ПИШЕШЬ ТАКОЙ ОСРВ BuguRTOS С НОВОЙ ИНТЕРЕСНОЙ ИДЕЕЙ...

@

ВЫКЛАДЫВАЕШЬ НОВОСТЬ НА LOR

@

В ОБСУЖДЕНИИ ТЕБЕ ДАЮТ ССЫЛКУ НА СТАТЬЮ ПРО FUTEX-Ы в LINUX...

@

ТЫ ИЗОБРЕЛ ВЕЛОСИПЕД!

@

Статью не читал, но реализация ивентов из неё подтекает так же, как сигналы в native API.

С другой стороны там более просто реализовано, в качестве усовершенствования пойдет!

Дерзай! Это сделает из тебя хорошего инженера.

ИМО, в статье интерес представляет ход и состав мыслей автора. А реализацию правильнее смотреть непосредственно в исходниках glibс , чтобы это был на самом деле работающий код, со всеми его нюансами.

Алсо, у разрабов musl libc были трудности с pthreads ( достаточно поискать по слову thread вот тут - https://git.musl-libc.org/cgit/musl/tree/WHATSNEW ). Не исключено, что у них в итоговой реализации есть какие-то интересные вещи. Я не смотрел.

А вот что я успел посмотреть - это CloudABI и дизайн-документ по реализации мьютексов/кондваров в нём. Сложилось впечатление, что быдло дилетантское.

CloudABI и дизайн-документ

Вот этот https://nuxi.nl/blog/2016/06/22/cloudabi-futexes.html

А вот что я успел посмотреть - это CloudABI и дизайн-документ по реализации мьютексов/кондваров в нём. Сложилось впечатление, что быдло дилетантское.

На самом деле в статье всё разжевано, а документ от CloudABI - тупикал пеар, оне не заморачиваются с мотивационной частью, а тупо констатируют факт принятия тех или иных решений.

Ну и ещё пропатчили Ядро, чтобы приделать туда свою capability based безопасность.

Судя по https://github.com/bminor/musl в мюслях:

a) не заморачивались с архитектурой мьютексов, тупо сделали по первому варианту из статьи.

б) с условными переменными сделали примерно то же, что и создатели CloudABI, только в юзерспейсе без необходимости корежить ядро.

И да, я тоже дилетантское быдло :)))