Сообщество весьма доброжелательное, проблема в том, что основной фон создают недовольные всякой фигнёй. Довольных обычно не видно и не слышно, зато фон из жалоб стабильно давит на мозг. Надо научиться не обращать внимание на неконструктивчик и выцеплять только действительно ценные замечания.
Сильный разработчик не жалуется, если тебе удалось написать востребованный проект, получай от него зарплату. У тебя сейчас реальный шанс перестать работать на дядю. В крайнем случае можешь перейти на более свободный график на основной работе, если тебя волнует стаж работы и запись в трудовой.
И да, спасибо за gitlab, но пора подумать, как получить с него профит.
Дарт Новопочитарсис — вчера прочитал в книге что-то новое, сегодня все будут внедрять эти идеи. Всё что написано до этого уныло и старо и подлежит полной аннигиляции.
Политику reference_existing_object на каждом классе не по разу приходится применять.
Политика manage_new_object сильно пореже, в основном на замену методам, возвращающим всякие unique_ptr, делаю вспомогательные функции, возвращаю в них результат unique_ptr::release() и прописываю питону прибраться как закончит.
Ещё две политики copy_const_reference и copy_non_const_reference нужны в основном для ссылок на std::string.
Если спрашиваете про классы с извращенскими конструкторами и без возможности копирования, то тоже часто приходится оборачивать. Люди порой такое API понапишут, хоть вешайся. Отовсюду торчать «интерфейсы» в виде абстрактных классов, куча синглтонов-фабрик, создающих unique_ptr на абстрактного предка. В общем не соскучишься.
Есть специфичные для России продукты: бухгалтерский учёт, складской учёт, электронный документооборот, электронная отчётность. Смысл делать её интернациональным пропадает уже после 200-й попытки рассказать, который из классов у тебя «Накладная» и как её «Провести».
В конце концов пишешь класс
class Накладная( Документ ):
def Провести( self ):
И это не считая всяких фреймворков для тестеров, пишуших скрипты тестирования, которым даже слова Логин и Пароль лучше писать по-русски, иначе не поймут.
Я в курсе, спасибо, но даже разработчик ядра питона может пару раз сказать вещи, которые расходятся с действительностью. Всё вышесказанное проверяется простой отладкой.
Помню всё это с удовольствием смотрел, наверное и сейчас бы в том возрасте тоже смотрел бы, передачи были хорошие.
И конечно же эта реклама поперёк логотипа программы, 90-е, где сейчас этот банк-спонсор «Барни»?..
Помню эту розовую ложку из Баскин Робинс в совсем другой передаче с другим ведущим, просто как вижу рекламу 90-х например в начале Зова джунглей, сразу эту Ложку вспоминаю… и как её потом на КВН отпинали
В общем, чем именно блокируется выполнение нативных потоков? Кроме как при импорте модулей, запрос к глобальным переменным нигде не происходит, там мы попадаем в мьютекс и спокойно всё получаем. Далее всевозможное API фактически уже не использует и не проверяет GIL.
PyGILState_Ensure мы делаем перед выполнением потока, import вполне можно сделать однажды на поток.
Собственно снова вопрос, что мешает потокам порождённым через boost::thread выполнятся параллельно?
Ничего.
Dict у каждого под-интерпретатора свой, обращение к нему безопасно для каждого из своего потока.
Да нет же, PyGILState_Ensure() который вызывается самым первым в конструкторе PyMainThread как раз возвращает PyGILState_LOCKED. Как раз захватывая GIL. После этого я его в главном потоке отпускаю аналогом Py_BEGIN_ALLOW_THREADS уже следующей инструкцией.
Во всех порождённых потоках вызов PyGILState_Ensure() возвращает уже PyGILState_UNLOCKED — причём ОДНОВРЕМЕННО. Без этой операции в потоке нельзя даже получить текущее состояние потока, нельзя сделать PyThreadState_Swap. Я его делаю сразу после PyGILState_Ensure, без этого получите падение.
После того как я завершаю работу по созданию под-интерпретатора, я подменяю состояние потока и освобождаю предыдущий hold. После чего спокойно делаю PyGILState_Ensure уже на новое состояние потока PyThreadState.
Далее изоляция происходит уже на уровне под-интерпетаторов. GIL действительно общий, уж простите что обозвал всё то что происходит множеством GIL, на самом деле всё это просто хитрый запуск множества изолированных под-интерпретаторов. Я не понимаю где это может не сработать, если есть нерабочий пример, прошу показать.
Прямо в продакшн: расширения функционала в виде классов и методов на Python.
Удобно: не требует компиляции и подцепляется простым перезапуском.
Опять же можно через Python подключиться и в режиме командной строки узнать много интересного о состоянии сервиса.
По сути сводим слой бизнес-логики к скриптовой обвязке над функциональным ядром скомпилированным на С++.
И да, спасибо за gitlab, но пора подумать, как получить с него профит.
Да, чёрт возьми, ты прав!
Политика manage_new_object сильно пореже, в основном на замену методам, возвращающим всякие unique_ptr, делаю вспомогательные функции, возвращаю в них результат unique_ptr::release() и прописываю питону прибраться как закончит.
Ещё две политики copy_const_reference и copy_non_const_reference нужны в основном для ссылок на std::string.
Если спрашиваете про классы с извращенскими конструкторами и без возможности копирования, то тоже часто приходится оборачивать. Люди порой такое API понапишут, хоть вешайся. Отовсюду торчать «интерфейсы» в виде абстрактных классов, куча синглтонов-фабрик, создающих unique_ptr на абстрактного предка. В общем не соскучишься.
Когда допилите GIL до изоляции на уровне суб-интерпретаторов?
Насчёт GIL — это просто bool, который устанавливается используя блокировку и не мешает многопоточно выполнять C++ коду в отдельном потоке.
Сделайте строковую константу кириллицей и присвойте её переменной.
В конце концов пишешь класс
И это не считая всяких фреймворков для тестеров, пишуших скрипты тестирования, которым даже слова Логин и Пароль лучше писать по-русски, иначе не поймут.
И конечно же эта реклама поперёк логотипа программы, 90-е, где сейчас этот банк-спонсор «Барни»?..
Помню эту розовую ложку из Баскин Робинс в совсем другой передаче с другим ведущим, просто как вижу рекламу 90-х например в начале Зова джунглей, сразу эту Ложку вспоминаю… и как её потом на КВН отпинали
PyGILState_Ensure мы делаем перед выполнением потока, import вполне можно сделать однажды на поток.
Собственно снова вопрос, что мешает потокам порождённым через boost::thread выполнятся параллельно?
Ничего.
Dict у каждого под-интерпретатора свой, обращение к нему безопасно для каждого из своего потока.
Во всех порождённых потоках вызов PyGILState_Ensure() возвращает уже PyGILState_UNLOCKED — причём ОДНОВРЕМЕННО. Без этой операции в потоке нельзя даже получить текущее состояние потока, нельзя сделать PyThreadState_Swap. Я его делаю сразу после PyGILState_Ensure, без этого получите падение.
После того как я завершаю работу по созданию под-интерпретатора, я подменяю состояние потока и освобождаю предыдущий hold. После чего спокойно делаю PyGILState_Ensure уже на новое состояние потока PyThreadState.
Далее изоляция происходит уже на уровне под-интерпетаторов. GIL действительно общий, уж простите что обозвал всё то что происходит множеством GIL, на самом деле всё это просто хитрый запуск множества изолированных под-интерпретаторов. Я не понимаю где это может не сработать, если есть нерабочий пример, прошу показать.
Удобно: не требует компиляции и подцепляется простым перезапуском.
Опять же можно через Python подключиться и в режиме командной строки узнать много интересного о состоянии сервиса.
По сути сводим слой бизнес-логики к скриптовой обвязке над функциональным ядром скомпилированным на С++.