Функция Linux fork по сравнению с Windows CreateProcess — что копируется?

Я портирую приложение Windows на Linux. я использую CreateProcess в Windows для запуска дочерних процессов и перенаправления всех стандартных потоков (in, out, error). Перенаправление потоков имеет решающее значение, основной процесс отправляет данные дочерним элементам и получает их выходные данные и сообщения об ошибках. Основной процесс очень большой, с большим объемом памяти и потоков, а дочерние процессы — маленькие. В Linux я вижу, что fork функция имеет аналогичную функциональность CreateProcess на винде. Тем не менее, руководство говорит, что fork «создает копию родительского процесса», включая код, данные и стек. Означает ли это, что если я создам копию огромного процесса, который использует 1 ГБ памяти только для запуска очень простого инструмента командной строки, который использует сам 1 МБ памяти, мне нужно будет сначала скопировать 1 ГБ памяти с помощью fork , а затем заменить этот 1 ГБ на 1 МБ процесса? Итак, если у меня есть 100 потоков, потребуется 100 ГБ памяти для запуска 100 процессов, для работы которых требуется всего 100 МБ? Также как насчет других потоков в родительском процессе, которые «не знают» о fork исполнение, что они будут делать? Какие fork Функция работает «под капотом» и действительно ли это эффективный способ создания множества маленьких дочерних процессов из огромного родительского процесса?

Решение

Когда вы звоните fork() затем изначально копируется только ваша виртуальная машина, а все страницы помечаются как копируемые при записи. У вашего нового дочернего процесса будет логическая копия виртуальной машины ваших родительских процессов, но он не будет потреблять дополнительную оперативную память, пока вы фактически не начнете писать в нее.

Что касается потоков, fork создает только один новый поток в дочернем процессе, который напоминает копию вызывающего потока.

Также, как только вы позвоните любому из exec Семейство вызовов (которое, я полагаю, вы хотите), затем весь образ процесса заменяется новым, и сохраняются только файловые дескрипторы.

Если ваш родительский процесс имеет много открытых файловых дескрипторов, то я предлагаю вам пройти /proc/self/fd и закройте все файловые дескрипторы в дочернем элементе, которые вам не нужны.

Другие решения

Копии «копируются при записи», поэтому, если ваш дочерний процесс не изменяет данные, он не будет использовать никакую память, кроме памяти родительского процесса. Как правило, после fork() Дочерний процесс делает exec() чтобы заменить программу этого процесса на другую, тогда вся память сбрасывается в любом случае.

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

Создание дочернего процесса выполняется чрезвычайно быстро, поскольку он использует те же страницы, что и родительский процесс. Страницы помечаются как копируемые при записи (COW), поэтому, если один из процессов изменяет страницу, другой не будет затронут. Когда существует дочерний процесс, он обычно вызывает один из exec функции, чтобы заменить себя с изображением. Windows не имеет эквивалента fork вместо CreateProcess Позвонить только позволяет начать новый процесс.

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

Я не использовал CreateProcess , но fork() не является точной копией процесса. Он создает дочерний процесс, но дочерний процесс начинает выполнение с так же инструкция, в которой родитель назвал fork и продолжает оттуда.

Я рекомендую взглянуть на Глава 5 из Три легкие фигуры ОС книга. Это может помочь вам начать поиск нужного вам ребенка.

Разветвленный дочерний процесс имеет почти все родительские средства скопированы: память, дескрипторы, текст и т. д. Единственное исключение — родительские потоки, они не копируются.

10 лучших GUI-клиентов Git для разработчиков

Перевод статьи «Top 10 Best GUI Git Client for Developers».

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

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

(Примечание редакции. Любопытно, что на сайтах вопросов и ответов многие отмечают, что использование GUI сильно упрощает рутинную работу, когда вы уже хорошо знакомы с принципом работы и командами Git).

Если вы ищете идеальный графический интерфейс для управления своим репозиторием на Mac, Windows или Linux, вам повезло: сейчас мы вам расскажем о лучших GUI-клиентах Git.

1. GitHub Desktop

GitHub Desktop это совершенно бесплатное приложение с открытым исходным кодом, разработанное GitHub. С его помощью можно взаимодействовать с GitHub (что и не удивительно), а также с другими платформами (включая Bitbucket и GitLab).

Функционал приложения позволяет легко замечать пул-реквесты в ветках, а также просматривать различия в версиях изображений и блоков кода. При этом элементы для дальнейшего управления можно добавлять в приложение даже путем перетаскивания.

Приложение доступно для macOS и Windows.

2. Fork

Fork это весьма продвинутый GUI-клиент для macOS и Windows (с бесплатным пробным периодом). В фокусе этого инструмента скорость, дружественность к пользователю и эффективность. К особенностям Fork можно отнести красивый вид, кнопки быстрого доступа, встроенную систему разрешения конфликтов слияния, менеджер репозитория, уведомления GitHub.

С помощью этого инструмента вам будут доступны интуитивный rebase в красивом UI, GIT LFS, cherry-pick, подмодули и многое другое.

3. Tower

Tower это платный графический интерфейс Git для macOS и Windows. В настоящее время это один из ведущих профессиональных инструментов подобного типа. С его помощью вы сможете лучше познакомиться с системой контроля версий. Вам будут доступны в визуальном представлении все действия, которые можно совершать в Git. Сюда входит и разрешение конфликтов слияния, и совместная работа над проектами.

Есть бесплатный пробный период.

4. Sourcetree

Sourcetree это бесплатный GUI Git для macOS и Windows. Его применение упрощает работу с контролем версий и позволяет сфокусироваться на действительно важных задачах.

Красивый пользовательский интерфейс дает возможность прямого доступа к потокам Git. К вашим услугам локальный поиск по коммитам, интерактивный rebase, менеджер удаленных репозиториев, поддержка больших файлов. Все происходящее вы можете видеть наглядно, а это очень облегчает понимание процессов.

Sourcetree был разработан Atlassian для Bitbucket, но вполне может использоваться в сочетании с другими Git-платформами. Имеет встроенную поддержку Mercurial-репозиториев.

5. SmartGit

SmartGit это Git-клиент для Mac, Linux и Windows. Имеет богатый функционал. Поддерживает пул-реквесты для SVN, GitHub и Bitbucket. В арсенале SmartGit вы найдете CLI для Git, графическое отображение слияний и истории коммитов, SSH-клиент, Git-Flow, программу для разрешения конфликтов слияния.

SmartGit может использоваться бесплатно в некоммерческих проектах.

6. Sublime Merge

Sublime Merge это клиент Git для Mac, Windows и Linux. Это детище тех же разработчиков, которые создали редактор кода Sublime Text.

Sublime Merge отличается высокой производительностью, а также отличным функционалом для слияния, поиска, просмотра различий между версиями. Базовой версией можно пользоваться бесплатно.

7. GitKraken

GitKraken это кроссплатформенный GUI Git для использования с различными платформами контроля версий (включая GitHub, Bitbucket, GitLab). Его цель — повысить вашу продуктивность в использовании Git. Для этого вам предоставляется интуитивный UI, возможность отслеживать задачи, встроенный редактор кода, редактор конфликтов слияния и поддержка интеграции с другими платформами.

Коммерческое использование платное. Также придется купить Pro-версию, если хотите получить расширенный функционал.

Доступен для Mac, Windows и Linux.

8. GitUp

GitUp это бесплатный (open-source) клиент Git для пользователей Mac. В этом инструменте упор сделан на скорость, простоту, эффективность и легкость использования. Он позволяет вам напрямую взаимодействовать с базой данных хранилища, в результате чего работает куда быстрее аналогов.

В GitUp вы найдете графическую альтернативу для всех функций Git и интуитивно понятную реализацию команд ввода.

9. Aurees Git Client

Это бесплатное приложение для использования Git на Mac, Windows и Linux. Создано оно для ускорения работы, связанной с контролем версий.

Здесь вы найдете отличный функционал для просмотра и редактирования разницы в версиях (с подсветкой), предварительный просмотр слияния версий, хорошую систему разрешения конфликтов слияния.

10. GitBlade

GitBlade — это красивый клиент Git для платформ Mac, Windows и Linux. В нем вы найдете все функции, необходимые в ежедневной работе с Git-проектами (инструменты merge, визуальное отображение связанных веток и коммитов, режим просмотра различий между версиями, визуализация истории файла).

Всеми базовыми функциями можно пользоваться бесплатно (а более продвинутыми — 14 дней пробного периода).

Это была десятка лучших клиентов Git с графическим интерфейсом. Все они подходящи для использования в Mac, большинство — в Windows и лишь некоторые — в Linux. Мы (редакция Techrocks) решили исправить эту небольшую несправедливость и добавить парочку клиентов Git для Ubuntu, которые не вошли в общий список. Описания — из статьи «Best 10 Git GUI Clients for Ubuntu».

11. Git Cola

Git Cola это совершенно бесплатный клиент Git для Ubuntu и других дистрибутивов Linux, а также Windows и macOS. Один из самых лучших и быстрых инструментов такого типа. Он прост в работе, но отлично справляется со всеми основными задачами, возникающими при работе с версиями.

12. GitEye

GitEye — простой в использовании клиент Git с графическим интерфейсом, созданный CollabNet. Поставляется в комплекте с несколькими инструментами, помогающими повысить продуктивность разработки ПО. Например, Gerrit Code Review выводит уведомления об изменениях или обновлениях в коде.

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

Этот клиент Git хорошо интегрируется с другими популярными инструментами, такими как Bugzilla, Jira, Hudson, Jenkins и пр.

Есть версии для Windows, Linux и Mac.

И напоследок — графический пользовательский интерфейс в виде сайта.

13. UnGit

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

UnGit также доступен в виде плагинов для Atom и Sublime Text.

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

fork() в MinGW.

Что делать, если на мингвине очень хочется форка?

Ничего не поделаешь, это Windows.

Смотри исходники Chromium’а. ЕМНИП в венде есть аналогичный механизм.

Хорошенько подумать, почему бы не использовать WinApi для создания потоков. Прямого аналога fork() на Windows нет, в частности, из-за того, что потоки в большинстве случаев удобно заменяют отдельные процессы.

Пока именно этим и занимаюсь.

Ещё один компелятор. Нет.

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

А где про них можно прочитать?

еще один компЕлятор будет если только добавишь его при установке cygwin’a
a сам cygwin — это не компилятор, это набор разных тулзов, ну вот http://www.cygwin.org/cygwin/

Прямого аналога fork() на Windows нет

А в перле как сделано?

А в перле свой fork, отдельный от системного.

Ну да, но ведёт он себя аналогично системному. Это я к тому, что навелосипедить можно, если очень хочется.

навелосипедить можно, если очень хочется

Так в cygwin, ЕМНИП, есть как раз такой велосипедный fork.

Через виндовые потоки.

Потоки таки не подходят. Они рушат всё приложение при крахе.

Можно ли нормально скомпилировать программу МинГВином, но с цугвиновскими библиотеками?

У меня не получилось — даже если подменить хидеры мингвина цугвиновскими и прилинковать libcygwin.a, сыпятся многочисленные варнинги на редефенишионсы.

Видно мингвин неявно линкует что-то, что конфликтует с именами цугвина. Справиться с этим не могу.

я бы выкинул минГВ %)

Совсем аналогичного нет 🙂 CreateProcess() имеет гораздо более высокую цену, чем fork(). В венде единицей диспетчеризации является поток.

В венде единицей диспетчеризации является поток.

Не знаю, к чему это, но в линуксе единица диспетчеризации тоже поток.

4.2 В линуксе потоки создаются на основе «легковесных процессов». Процесс в винде гораздо тяжелее. И модель «мультипроцессности», которая опирается на fork() под виндой становится УГ, потому что создатели CreateProcess() ничего похожего не имели в виду.

CreateProcess() имеет гораздо более высокую цену, чем fork(). В венде единицей диспетчеризации является поток.

И причем тут вообще единица диспетчеризации?

4.2 В линуксе потоки создаются на основе «легковесных процессов».

И это не мешает планировщику выполнять потоки как отдельные сущности.

В каком смысле «тяжелее»? Контекста больше, запустить труднее?

И модель «мультипроцессности», которая опирается на fork() под виндой становится УГ, потому что создатели CreateProcess() ничего похожего не имели в виду.

Как это связано с диспетчеризацией?

не поток, а task.
Процесс это task, и тред это task.

В винде процесс это просто контейнер, и единица выполнения там тред.

не поток, а task.
Процесс это task, и тред это task.

okay.jpg. Но это больше вопрос терминологии, не?

нет, отличие фундаментально.

хотя Native API и позволяет сделать fork, через некоторые хитрости, но надо понимать, что в винде у процесса нет «состояния выполнения», как оно у процессов в unix-like системах. У процесса есть виртуальная память, коллекция тредов и другие штуки, но сам процесс это просто контейнер, по процессам время исполнения не квантуется.

хотя Native API и позволяет сделать fork, через некоторые хитрости, но надо понимать, что в винде у процесса нет «состояния выполнения», как оно у процессов в unix-like системах. У процесса есть виртуальная память, коллекция тредов и другие штуки, но сам процесс это просто контейнер, по процессам время исполнения не квантуется.

Нет нет, с вендой я согласен. Вендовый процесс как я понимаю, больше похож на task из L4. Я хотел сказать что «light-weight process», «thread» в других unix-like OS и task в линуксе — принципиально похожие сущности с разными названиями.

Вопрос ТСа относился к «тому же самому» под оффтопиком. Ну так «того же самого» на деле-то и нет. И вытекает это не из различий в терминологии 🙂 (Дело не в похожести, а в различиях)