типа такой конструкции

и если это класс, конечно

Спасибо!

У нас случайно нет реализации протокола fast cgi?

https://code.dlang.org/packages/fcgi-loop

хз, 2015

возможно это важно

https://code.dlang.org/packages/cgi_d более свежий, но, видимо без fast cgi

http://arsdnet.net/web.d/cgi.d.html тут вроде есть

А где хранятся глобальные переменные разные? Это от языка зависит?

Зависит, конечно. У C/C++/D есть например "сегмент данных" под это дело. Но в Ди это лишь для __gshared, просто "глобальные" у него ж thread-local.

А вот так мы получается что сделаем. int в куче расположим? int* p = new int;

да

а какой реальный юзер-кейс у этого случая?

никакой

Я когда мысленно представляю как эти программы выделяют память десятками вызовов, представляю какой там ад творится с фрагментацией, как только оптимизатор все это перемалывает..

Никак, оптимизатор в выделение памяти не смеет вмешиваться обычно, т.к. это было бы изменением результатов выполнения...

А стек файбера это иначе называется "стек фрейм"?

вообще стэк-фрейм это фрагмент стека, сожержащий адрес возврата, аргументы и локальные данные функции. Вот кстати, в сорцах core.thread неплохие каменты по файберам https://github.com/dlang/druntime/blob/master/src/core/thread.d#L3827

да комменты реально хорошие

А квант времени как рассчитывается при переключении между приложениями. В приложении же может быть 100 потоков, а может быть один? Получается если в приложении сто потоков то квант выделенный на весь процесс делится на 100 ? Чnобы каждый поток успел поработать?

подозреваю, это очень сильно зависит от операционной системы и ее планировщика

http://www.cyberguru.ru/win32/windows-processes-page2.html тут вот в общем и целом описано, как это работает в семействе winNT

@deviator в питоне все же потоки поверх системных, но все остальное там сбоку прикручено

@deviator в питоне все же потоки поверх системных, но все остальное там сбоку прикручено

Йа ни эксперт) насколько я помню там вся реальная многопоточность реализована через запуск новых инстансов интерпретатора. А файберы там как файберы (по всей видимости 'почти', ибо без понятия оперирует ли пользовательский код регистрами напрямую под капотом, но думаю нет)

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

В Ди по идее тоже самое, только у питоне с потоками какая-то херь с GIL типа потоки могут тормозить из-за доступа к разделяемым данным.

А что значит тогда 'сбоку'?

большинство структур данных (списки, словари и т.д.), которые находятся в глобальном пространстве интерпретатора, не потоко-безопасны. Поэтому придумали костыль в виде GIL

Интересно

А в каком языке они потокобезопасны?

Везде нужны блокировки

GIL из-за того что сложно определить к чему нужно доступ защищать

Типа всё тормознул и всё

Вообще чистый питон не для таких задач

В Ди же много данных immutable т.е. их не попортить

А либы все серьезные имеют в основе С

В Ди же много данных immutable т.е. их не попортить

Строки только по умолчанию

А в каком языке они потокобезопасны?

Возможно в Pony они безопасноы ?

Ну мы же о нормальных языках)

Но в Ди разве есть GIL ? Или я тогда что-то не понимаю. Почему в Питоне есть проблема, а в Ди нет

Но в Ди разве есть GIL ? Или я тогда что-то не понимаю. Почему в Питоне есть проблема, а в Ди нет

Ну во первых д не интерпретируемый

а как это связано с потоками?

По сути проблема то остается

По сути проблема то остается

Ну смысл в том, что gil прост и удобен

А d нужна скорость, как и всем компилируемый языкам

Какой смысл в чём-то подобном там?

а как это связано с потоками?

дело в том, что в интерпретаторе много глобальных объектов, которые используются в интерпретируемом коде, и делать их копии пока что большая проблема. Дело совсем не контейнерах, дело вообще в низкоуровневынх объектах

к примеру каких объетов?

может про D поговорим?

зайдите в Python чат и там спросите

может про D поговорим?

+

gil — это когда в многопроцессорных системах принудительно блокирует потоки, чтобы в единицу времени исполнялся только один?

gil — это когда в многопроцессорных системах принудительно блокирует потоки, чтобы в единицу времени исполнялся только один?

не совсем

gil — это когда в многопроцессорных системах принудительно блокирует потоки, чтобы в единицу времени исполнялся только один?

Но что-то вроде

gil — это когда в многопроцессорных системах принудительно блокирует потоки, чтобы в единицу времени исполнялся только один?

Касательно одного интерпретатора

libasync проблемный или vibe.d?

Я просто взялся с товарищем за реализацию fcgi. И для тестов пришлось еще сервер создать. И я подумал, что может уже есть наработки для создания сервера.

в либасинке мне так и не удалось настроить работающий ThreadPool с переиспользованием входящего сокета.

Но в целом он работает.

С другой стороны, мне кажется vibe.d:core это уже стандарт де-факто для всех библиотек, если какая-то библиотека хочет поддерживать асинхронный режим работы, то она должна делать это на основе vibe.d

и это плохо)

Ну а щито поделать

брать волю в кулак и пилить альтернативу)

Это только усилит страдания и раскол в рядах.

благо, это не фронтэнд, в котором при всем желании не избавиться от js)

ERROR: S client not available

Единого стандарта/интерфейса асинхронной архитектуры нету, это значит что каждый ее переизобретает снова и снова. И библиоткеи друг с другом несовместимы.

С другой стороны, мне кажется vibe.d:core это уже стандарт де-факто для всех библиотек, если какая-то библиотека хочет поддерживать асинхронный режим работы, то она должна делать это на основе vibe.d

Vibe.d:core. Есть его ядро, которое можно поставить отдельно?

vibe слишком комбайн, и как мне кажется, он становится заложником своей архитектуры

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

Как раз чтобы была единая минималистичная библиотека. Ее даже стараются писать без GC

Это ядро не комбайн?)

ну вроде как да)

Ну там же как бы есть куча других пакетов - работа с json, http, weforms, mongodb, templates и т.д. Но это все в ядро не входит.

но там все сложно)

Ядро это только event loop + асинхронные стримы

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

наверное, даже это вот можно попробовать использовать https://github.com/vibe-d/vibe-core

наверное, даже это вот можно попробовать использовать https://github.com/vibe-d/vibe-core

Об этом и говорил @chebotarevp думаю

Да

не, есть vibe.d:core, а есть vibe-core — дальнейшее развитие идеи)

Хм я думал это одно и то же

This is the designated successor of the vibe-d:core sub package of vibe.d 0.7.x. The API is mostly compatible from a library user point of view, but the whole library has received some heavy lifting under the surface, close to a rewrite.

Но в общем да, видишь тут еще заявлена поддержка файберов, что важно. У libasync нету файберов.

Я скажу прямо, что меня интересует backend. И я вижу, что все пытаются сделать сервера сразу. Я думаю, что проблему можно решить поэтапно. Сделать реализацию fcgi, сделать менеджер процессов (вроде php-fpm). Потом можно делать веб фреймворк (только не в духе Django, когда все в одном), а в духе symfony или flask (когда несколько компонентов)

начать можно даже с scgi)

Я скажу прямо, что меня интересует backend. И я вижу, что все пытаются сделать сервера сразу. Я думаю, что проблему можно решить поэтапно. Сделать реализацию fcgi, сделать менеджер процессов (вроде php-fpm). Потом можно делать веб фреймворк (только не в духе Django, когда все в одном), а в духе symfony или flask (когда несколько компонентов)

Я согласен, это хорошая идея

Просто многие переоценивают свою разработческую волю, а разработчик может не так уж много кода поддерживать

Поэтому поэтапно и покусочно

Если каждый будет мейнтейнить по 2-3 небольших пакета, будет здорово

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

иначе все это порастет сорняками и умрет

До бэкенда еще далеко, сначала либа и менеджер

Я посмотрел на perl менеджер, там около 10к строк кода

под бэкэндом я имею в виду, что-то, отдающее в конечном итоге данные по http

это может быть и fcgi, и scgi, и даже просто cgi для знающих ток в извращениях, или даже модуль для nginx или apache, или, о боги, целый сервер)

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

иначе бытовуха затянет, и все начинания затухнут