abduraxman2: на пальцах можно попробовать )))
Если грубо - у проца есть сигналы /RW /WR и ША и ШД (грубо - потому что шина может быть мульциплексированная и есть доп сигналы для "защелкивания" адреса и данных; или вместо /RW /WR четыре битак команды как у SD/DDR). ARM такой. Моторолы древние если мне память не изменяет.
У таких процов запись\чтение в память не отличается от записи\чтения в порт - ибо это разраб устройства определяет как он дешифровывает шину и по каким адресам у него память а по каким IO (GPIO, порт принтера и тп).
Есть процы у которых помимо /RW /WR есть еще два сигнала - /MEM и /IO - x86 и Z80 из того что вот сразу в память попадает. Там вот - в таких инструкции доступа в память и порты различаются и соответсвенно в зависимости от инструкции /MEM и /IO выставляются - ```mov [bp], ax``` vs ```out [bp], ax```.
Ну а по второму - так это просто как эти древние недостатки обходятся лет 30 (если не больше) - фиксировання длинна и слишком большая -> убираем фикисрованную длинну и наиболее ходовые операции ставим в наиболее короткие коды
потеря одного операнда -> используем три операнда
слишком длинная команда -> используем относительную (регистр + смещение) или не прямую адресацию (адрес не в команде а в регистре)
низкое быстродействие изза доступа к памяти -> кэшируем, если грубо
Собственно изза того что те "недостаки" можно обойти, они и становятся не точными и ошибочными.
perrfect: вайршарком посмотри. похоже там еще и пакет размером меньшим чем мту. читит ли провайдер с icmp опятьже видно будет.
вообще тфтп тормоз тот еще - мы в свое время сервер себе переписывали чтоб полностью сетку загрузить.
Сюда надо вставить картинку про время удивительных историй. А также ссылку на man htop, и продвинутый туториал по pthread (включая аффинити) с картинками
Павел Каптур: скорее всего SIGPIPE всему виной. Освой strace и посмотри, что точно происходит (```strace -f -o log.file.name.txt ./my-mega-app arg1 arg2```).
Скорее всего родительский stdout\stdin\stderr закрывается при смерти родителя, и при попытке вывода из ребенка он получает SIGPIPE. Но там же может быть и чтото иное. Вариантов решения там тоже полно получается - от игнора сигнала с аккуратным завершением ребенка, до всяких выкрутасов чтобы у ребенка файлы были живы и выводились тудаже куда и у родителя.
Форк родительского процесс и не должен после execv существовать (за исключением ошибки в execv - к примеру нет программы для запуска) - вся его память будет заменена на код запускаемой программы. То что там с stderr stdout проблемы - проще strace посмотреть.
Если надо из родительского процесса запустить и получить статут - то system используй. С stdout stderr проблем не должно быть особо. Ну а если надо в родительском весь вывод ребенка получить - то popen.
И system и popen через exec* реализованны.
Про путь Erlang -> Golang можно сказать "принципиально". Golang -> Erlang все в разы проще же.
Циклы могут быть проблемой - но если го чисто SSA делает - то должны работать с первого дня.
Goto может быть проблемой.
Олексiй Чечель: Ну да - GOARCH GOOS перебирать к примеру. Плюс там доп таски всякие для CI, зависимости втянуть, тестов разных и пр. Если не как башем им пользоваться и зависимости правильно прописывать (а не сплошные .PHONY) то лишней работы и не делает
Виталий Филинков: Для того, чтобы билдование не зависило от хоста и системы (к примеру в недавнем Ubuntu LTS дефолтный make обновили и там есть различия с 3.81 - но и предыдущий не так работает как ванильный 3.81. и это не считая десятилетних билдхостов). Скрипт же - потому что не генерирует именованный бинарь и не компилируется по go build.
