так. Мне копать в event loop?

https://habrahabr.ru/post/336498/ вот, вроде, в статье как раз рассказывают, как event loop в libuv устроен)

https://habrahabr.ru/post/336498/ вот, вроде, в статье как раз рассказывают, как event loop в libuv устроен)

я понял

сегодня прочту

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

про epoll, Kqueue вот это вот все)

"За всю мою карьеру, необходимость написать код, который запускает второй рабочий поток, возникала, вероятно, менее полудюжины раз." и это говорят люди которые разработкой по 20 лет занимаются

меня больше интересует масштабирование, безопасность чем что там в кишках делается - вот тут если кто может что-то посоветоввать, буду рад

Я много читал последние дни про это прихожу к мысли что лучшее масштабирование это изолированные данные и по процессу на ядро. Все остальное — тупо оптимизация кода

что есть "изолированные данные"?

thread local?)

у меня 8 серверов. надо чтоб данньіе дублировались минимум 3-4 раза + нагрузка делилась максимально равномерно

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

ну и осталось сделать еще один шаг и признаться, что для распараллеливания идеально подходит функциональное программирование)

ну распаралеливание разве не на стороне БД будет?

3 дня назад решил поюзать dlangide - 3 бага за пол часа запостил, в сравнении с тем что бьіло год назад - намного лучше, но все еще пилить и пилить(

"За всю мою карьеру, необходимость написать код, который запускает второй рабочий поток, возникала, вероятно, менее полудюжины раз." и это говорят люди которые разработкой по 20 лет занимаются

Любое gui приложение до эры файберов)

я имею ввиду какие паттерны которые лежат в основе любого сервера

http://aosabook.org/en/index.html ?

http://aosabook.org/en/index.html ?

мне кажется тут про всякое разное, не только про то, что мне надо. Верно?

да, там надо выбирать проекты подходящие

тот же nginx описан

Любое gui приложение до эры файберов)

А разве файберы в гуи используются?

А разве файберы в гуи используются?

А в чём фундаментальная проблема? Может 'не стиль', но мне норм, приложения 4 так сделал...

как мы тут пришли недавно к выводу в C# async/await выполняет роль тех же файберов и активно используется в GUI)

А в чём фундаментальная проблема? Может 'не стиль', но мне норм, приложения 4 так сделал...

просто как я понимаю они для совсем уж легковесных операций были задуманы. Хотя по идее их можно же и как потоки использовать не вызывая yield

Они для IO операций задуманы

если не вызывать yield, в файберах нет особого смысла

Там где надо ждать пока запишутся данные в сокет или прочитаются.

как мы тут пришли недавно к выводу в C# async/await выполняет роль тех же файберов и активно используется в GUI)

ды к чудес то не бывает, либо процессы, либо потоки, либо игрища с сохранением контектса)

просто как я понимаю они для совсем уж легковесных операций были задуманы. Хотя по идее их можно же и как потоки использовать не вызывая yield

Без yield нет переключения контекста - нет псевдопаралельности

И, следовательно, бессмысленно в gui

а ты в каких местах для гуи его использовал?

а ты в каких местах для гуи его использовал?

Не совсем понял вопрос...

ну какие операции ты в гуи проводил в файберах. к примеру отрисовка окна и рассчеты в самой проге

Ну у гуя есть свой эвентлуп, его пошагово можно крутить в файбере, можно на его основе запускать работу файбера

Но по хорошему, всё-таки это 'не стиль')

Вот что нашел про Ди и потокобезопасность: "However, the other major thing that needs to be pointed out is that all data in D is thread-local by default. So, you can't access data across threads unless it's explicitly shared. So, you don't normally have to worry about thread safety at all. It's only when you explicitly share data that it's an issue."

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

Да и вроде это давно известная всем тема

Ну, всмысле, что это не недавно появилось и они эту систему типов и сам tls позиционируют как одну из ключевых фич

В D1 вроде бы не так было...

ну так-то да, скажем так, встроенная в язык защита от выстрела в ногу

но как только понадобится обмениваться данными между потоками, появятся все те же прелести, что и в C/C++

И да, я праивльно понимаю, что в других языках Java/C#/python такого меньше и *не все* данные тред-локал?

но как только понадобится обмениваться данными между потоками, появятся все те же прелести, что и в C/C++

Дык, а где они не появятся?

в языках, где нет данных)

?

ну функциональщина там всякая, но что-то она с трудом взлетает

Функциональщина выглядит очень прелестно, пока не встаёт надобность в IO.

другими словами, пока она не встречает «данные» на свем пути)

нет в жизни счастья

Скорее побочные эффекты, чем данные.

ну да, они и есть)

грубо говоря, функция, которая возвращает разные значения при разных входных параматерах автоматом превращается в некую «переменную», хранящую состояние, что ломает концепцию сферических функциональных языков в вакууме

и тут начинаются всякие мьютексы и обмен сообщениями

А концепция месседж-пассинг это попытка реализовать пококобезопасность или это немного не о том?

но как только понадобится обмениваться данными между потоками, появятся все те же прелести, что и в C/C++

Ну не совсем

В D система типов не позволит те же проблемы поиметь что и в C++

а какие к примеру?

у меня 8 серверов. надо чтоб данньіе дублировались минимум 3-4 раза + нагрузка делилась максимально равномерно

А зачем данные дублировать?

чтоб если один сервер накроется, ничего не случилось плохого с данньіми

как рейд-массив

но на уровне не дисков, а серверов

например. в одном дата-центре что-то случится с инетом или светом...

У меня как раз вчера был порыв начать пилить систему синхронизации на D, но погуглив я понял что все уже давно придумано и разработано :)

Что-то я не понял, а БД на что?

Или о каких данных идёт речь?

ERROR: S client not available

Файлы

В таком случае делается централизованная система хранения файлов, которая сама по себе распределенная

Аналог S3

Но на уровне app его дублировать - не верно

Точнее можно, но этим должно заниматься не основное приложение, а то, которое отвечает за его (файла) хранение

Не то, что производит бизнес логику

Основное приложение должно по API получать/обновлять/удалять эти файлы из второго приложения, которое отвечает исключительно за его хранение и, возможно, за его масштабирование...

Как пример - MongoFS

Не твоё приложение его (файл) масштабирует, а "сторедж", в лице MongoFS

Тогда ты не ограничен 8ю серверами или какой-то иной инфроструктурой...

Ну вот есть решения вроде GlusterFS

Но он, как мне сказали, жрет ресурсы

Их много

То же сепх

Есть более легковесные

ceph это жесть )

Согласен, его нужно уметь готовить

Требует спец. разметки диска, двойного резервирования, минимум 3 ноды в кластере и кучу других оверхедов

Но он реально крут, если его верно настроить.

Так что ты подумай в эту сторону, а не дублирования.

Зачем мне думать в эту сторону? Вся его крутость мне совершенно не нужна.

Нужно просто синхронизировать пару десятков гигов файлов между двумя серверами. Без отказоустойчивости и транзакционности.

У меня в загашник есть идея написать распределенную систему сообщений, но времени до нее добраться нет :(

Я Степаносу отвечал :)

Ну так рсинк тебе в помощь!

Самое что не есть простое решение

Положи файл и засинкай его

Новый dmd вышел

Чего там хорошего?

2.076.1 https://dlang.org/changelog/2.076.1.html Просто кучка багфиксов.

2.076.1 https://dlang.org/changelog/2.076.1.html Просто кучка багфиксов.

По мне так багфиксы это очень хорошо

Это верно.