КОМПРОМИСС НЕ ДЛЯ НАС

я тоже не против смешения разных ЯП в 1 проекте, если в каком-нибудь проекте есть узкие места и 2-3% всего кода переведут на С/С++ - в этом нет ничего плохого, это самые быстрые языки программирования.. все игровые проекты вообще полностью на С++ пишут (движки ААА-класса типа CryEngine )

В @devops_jobs плз

я тоже не против смешения разных ЯП в 1 проекте, если в каком-нибудь проекте есть узкие места и 2-3% всего кода переведут на С/С++ - в этом нет ничего плохого, это самые быстрые языки программирования.. все игровые проекты вообще полностью на С++ пишут (движки ААА-класса типа CryEngine )

Движки ааа класса не очень хороший пример оптимизации кода

просто когда нужна высокая производительность - берут С/С++, главное, не стремиться весь код писать на нём)

просто когда нужна высокая производительность - берут С/С++, главное, не стремиться весь код писать на нём)

Не всегда си++ самый быстрый

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

ИМХО C\C++ это прежде всего дисциплина

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

Паш вон на жабе быстрый код пишет, но не говорит что он быстрый ?

насколько я знаю, на жаве вполе реально писать быстрый код

притом, ведь, зараза даже падать не будет

а если будет - будет давать внятный стектрейс

Опять непонятные слова

Опять непонятные слова

Эта та простыня, которая магия.

Кстати, один из лучших трейсов, что я видел у джавы

Эта та простыня, которая магия.

Да эт я так

в java хоть понятно где и что нетак... пошёл писать скрипт на python, где вывод хуй знает

?

так и не зря же эти ЯП популярны) С/С++ / Java / Python, пройдут десятилетия, а они будут по-прежнему живы

в java хоть понятно где и что нетак... пошёл писать скрипт на python, где вывод хуй знает

на питоне всё просто

в java хоть понятно где и что нетак... пошёл писать скрипт на python, где вывод хуй знает

>>> raise NotImplementedError('Pony') Traceback (most recent call last): File "<stdin>", line 1, in <module> NotImplementedError: Pony

хе

gdb многое разъясняет

не знаю как там в явах

нафиг эти яп

яп от яп

gdb многое разъясняет

в питоне есть https://docs.python.org/3.6/library/pdb.html , ещё PyDev..

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

вообще код, который полгается, на copy-on-write после форка, смотрится очень стрёмно и плохо переносится

С чего бы вдруг? Например, так редис снапшотится

С чего бы вдруг? Например, так редис снапшотится

ничего не понимаю. Что значит снапшотится?

причина может звучать хотя бы так — а что если этот редис захотят собрать на какой-нибудь другой юникс подобной среде? Ну и вообще, код, который делает не то, что подразумевает — по умолчанию говно

конечно, можно написать комментарий на 20 строк

в питоне есть https://docs.python.org/3.6/library/pdb.html , ещё PyDev..

Для pypy клевый отладчик

У них там свой

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

@lorddaedra https://morepypy.blogspot.nl/2016/09/revdb-released-v541.html?m=1

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

так ты в этих узких местах получаешь полный менеджмент памяти и пр.

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

причина может звучать хотя бы так — а что если этот редис захотят собрать на какой-нибудь другой юникс подобной среде? Ну и вообще, код, который делает не то, что подразумевает — по умолчанию говно

fork - это всегда cow.

ничего не понимаю. Что значит снапшотится?

redis - это in-memory db. Для персистентности использует снапшоты. Чтобы снять снапшот делается fork и дочерний процесс пишет дамп на диск.

а со SlamData кто-нить работал?

fork - это всегда cow.

не всегда. Тенденции меняются, а библиотечные вызовы — почти всегда нет, так как эти библиотеки создавали, чтобы изолировать системные вызовы. Это сделанно, чтобы на всех ОС, стандартный библиотечные вызовы вели себя одинаково. Так cow в fork приехал, не исключено, что так же он и уедет.

есть такое понятие, как управление сложностью. Когда я пишу fork() я вкладываю в это определённый смысл. Я хочу передать некоторую семантику читающему. Если я оперирую терминами cow, я, пожалуй лучше напишу clone()

redis - это in-memory db. Для персистентности использует снапшоты. Чтобы снять снапшот делается fork и дочерний процесс пишет дамп на диск.

а одновременно несколько дампов создаваться может? Один дамп на процесс?

не всегда. Тенденции меняются, а библиотечные вызовы — почти всегда нет, так как эти библиотеки создавали, чтобы изолировать системные вызовы. Это сделанно, чтобы на всех ОС, стандартный библиотечные вызовы вели себя одинаково. Так cow в fork приехал, не исключено, что так же он и уедет.

есть такое понимание как стандарт, в нем прописано поведение. Пока ОС следует стандарту, поведение сохраняется. Это так для fork.

Поэтому и CoW - это всегда есть.

а одновременно несколько дампов создаваться может? Один дамп на процесс?

Нет

есть такое понятие, как управление сложностью. Когда я пишу fork() я вкладываю в это определённый смысл. Я хочу передать некоторую семантику читающему. Если я оперирую терминами cow, я, пожалуй лучше напишу clone()

clone - linux-only системный вызов

есть такое понятие, как управление сложностью. Когда я пишу fork() я вкладываю в это определённый смысл. Я хочу передать некоторую семантику читающему. Если я оперирую терминами cow, я, пожалуй лучше напишу clone()

http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html

если ты используешь клон ты говоришь "плевать я хотел на всех кто пользуется не линуксом", и ничего кроме.

если ты используешь клон ты говоришь "плевать я хотел на всех кто пользуется не линуксом", и ничего кроме.

Угу. Именно.

Ну и если честно копировать память, то fork процесса с 16gb res будет забавным

если ты используешь клон ты говоришь "плевать я хотел на всех кто пользуется не линуксом", и ничего кроме.

конечно. На этапе компеляции, на фрибсд компилятор выдаст соостветствующую ошибку. Это лучше, чем программа запустится, но будет содержать темпоральные баги или работать медленно

конечно. На этапе компеляции, на фрибсд компилятор выдаст соостветствующую ошибку. Это лучше, чем программа запустится, но будет содержать темпоральные баги или работать медленно

только вот такого не будет в случаи с fork

ещё хочу сказать, что мне очень жаль программистов, которым приходится писать, например под freebsd

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

отсюда неправильные выводы

Слушайте, ну есть single unix spec. Если писать по нему - все будет ок

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

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

Да, не будет epoll/kqueue

ещё хочу сказать, что мне очень жаль программистов, которым приходится писать, например под freebsd

Я тут заморочился с тем чтоб помочь портировать одну из софтин под Макось.

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

есть жесткий контракт - posix называется.

ты его неправильно понимаешь, поэтому зачем-то для CoW семантики предлагаешь использовать linux-only non-posix syscall

это честно говоря бред

и тому кто будет потом твой код читать резонно захочется дать тебе в морду за такое

И хорошо если это будешь ты через 2-3 года

ERROR: S client not available

есть жесткий контракт - posix называется.

но посикс ничего не говорит про cow

посикс описывает поведение fork, в ограниченном виде

это классика для мира unix программирования. Кошка бросила котят, пусть ебуться как хотят :)

если бы была дока, где написанно, что дочерний процесс ДОЛЖЕН содержать побитовую копию образа виртуальной памяти основного процесса — базар был бы нулевой

а так линукс cow придумал. plan9 вводит rfork() который тоже по-своему себя ведёт

@abagrintsev ок, делай как считаешь нужным, но то что ты делаешь - дебилизм с моей точки зрения

ну смотри

давай со своей колокольни объясню. Не обязательно считать, что моя точка зрения истина в последней инстанции

ну давай

вот ты написал программу, её приняли, протестировали всячески (иногда бывает, что некоторые баги можно поймать только под нагрузками) и вдруг кто-то из админов решил, что линукс говно, надо срочно ставить plan9, потому, что модно, молодёжно и т.д.

вообще, у нас, на уровне cmake и либ такое пресекается

но речь не об этом

вот ты написал программу, её приняли, протестировали всячески (иногда бывает, что некоторые баги можно поймать только под нагрузками) и вдруг кто-то из админов решил, что линукс говно, надо срочно ставить plan9, потому, что модно, молодёжно и т.д.

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

не всё так просто

по причинам изменичовсти того же fork() в завимисоти от окружения, хорошим тоном было бы такие вызовы писать под #ifdef

причём, под #else лучше вообще писать abort() :)

потому что ты уволишься, программу поддерживать не будут, а вспоминать будут именно тебя :)

по причинам изменичовсти того же fork() в завимисоти от окружения, хорошим тоном было бы такие вызовы писать под #ifdef

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

притом взамен того что в 100% реальных случаях на ближайшие 5 лет будет работать нормально?

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

ты бы вспоминал не в этом случае

куда дольше и жирнее чем если бы твоя софтина криво работала бы на план9

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

а дело в том, что компилируется — ещё не значит, что работает

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

поэтому перед продакшеном всегда следует тест, если это не стартап

функциональное и нагрузочное тестирование как минимум

cmake могут поравить, он может найти нужный libc, который на самом деле glibc или uclibc (обе имеют "обратную совместимость" с мелкими подписями под звёздочками), но этого не узнаешь. В твоём доме будет играть музыка, но ты ещё не услышешь :)

cmake могут поравить, он может найти нужный libc, который на самом деле glibc или uclibc (обе имеют "обратную совместимость" с мелкими подписями под звёздочками), но этого не узнаешь. В твоём доме будет играть музыка, но ты ещё не услышешь :)

вот зато если ты начнешь собирать такой код и какой-нибудь дебил напишет clone вместо fork, то первое что я скажу это "что за чудак (на букву м) написал в этом месте clone без нужды?"

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

понимая что писалась она под линукс

вот зато если ты начнешь собирать такой код и какой-нибудь дебил напишет clone вместо fork, то первое что я скажу это "что за чудак (на букву м) написал в этом месте clone без нужды?"

ты бы знал, сколько я по неопытности так говорил. В процессе набивания шишок многое в восприятии поменялось

и еще подумаю что разраб был молодцом, писал сразу портируемый код