Разделить программу на 47 процессов это конечно очень круто, но не лучше ли иметь один процесс с 47 потоками и единым адресным пространством?
Или питон на столько прост что надо усложнить обмен между кусками кода?

xneo, готов поспорить на кегу гиннесса, что ты решаешь проблему, которой у тебя нет.
Надо писать код так, чтобы было всё равно, на одном сервере он работает, или на двадцати. А если двадцати не хватит, то добавить ещё. Это вопрос правильной архитектуры приложения.

Если у меня сервис будет разнесён на несколько процессов/серверов это:
- дополнительные потери на оплату и поддержку серверов;
- дополнительные сложности/ошибки/потери производительности для их синхронизации.

Могло бы ведь оно работать на одном сервере на 64 ядрах/100500 потоках в едином адресном пространстве/процессе?

Вот отображается, допустим, ТОР-100 юзеров на сайте. Стоит 20 серверов. Это должен рассчитывать каждый сервер/каждый процесс? Или рассчитывает главный процесс и раздаёт дочерним? Главный вопрос - зачем? Ведь могло бы это всё работать в одном процессе. И сразу уходит куча лишних вопросов.

xneo
И сразу уходит куча лишних вопросов.

Одни уходят другие приходят. Разделение на процессы делают для повышения живучести и разделения пространства имен и адресов. По мере совершенствования технологий программирования идет медленный переход от процессов к тредам. Хром в этом смысле плывет против течения.

xneo, таки моя кега остаётся при мне. Вопросы из разряда “я в школе бейсик изучал, а сейчас вот на питон смотрю и думаю, как на нём писать, ведь там есть страшный и ужасный GIL, который всё портит”. Ты сначала столкнись с ситуацией, где GIL тебе помешает и только тогда думай, как это решать. Не раньше.

Про TOP-100 совсем как-то страшно. Для начала тебе надо, наверное, про базы данных почитать… Или может ну его нафиг это программирование? А то ещё захочешь написать язык, где все переменные глобальные…

Про браузеры это Ха ха .
МУжики, вы просто хорошо живете, а я нет =) И я лично вижу проблему.
Я живу в регионе где с интернетом плохо, а на работе еще хуже. Там у меня литит скорсоти это где то 32 кб/с и лимит tcp подключений в районе 14 (юзеры сидят через прокси). Пользуюсь я ФайрФоксом и на современных “тяжелых” страницах я постоянно наблюдаю картину когда Лиса просто фризится при открытии новой вкладки, на 2-5 секунд. Или пока грузиться новая вкладка лагает весь браузер. И про падения я скажу, что лично не однократно наблюдал как ОгнеЛис, весь процесс, аварийно завершался при явной проблеме в содержимом вкладки, вроде это было из за Flash объекта.
У себя на домашнем ПК ситуация с интернетом лучше, но и там я чувствую такую проблему (веротяно из за того что пинг 750мс ЛИСА также подтуплять может).
А вот с Хромом таких проблем нет. Просто нет. Живу и конкретно в этом вопросе радуюсь.

Раньше было жить не так плохо - потому что не было такого чудовищного веб траффика, не было раздутых JS, картинки были маленькими, страницы писались более лаконично. Время другое было, условия другие были.

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

ZZZ, Не волнуйся, программировать я начал намного раньше тебя. И с БД знаком. И в ТОР-5 на фриланс-бирже входил ещё лет 5 назад И модули ядра писал на С под IPTables/Linux. С лёгкостью отличу коллизии Wi-Fi от коллизий хеш-функции, Atmel от ST. Ну не писал на питоне, что уж тут…

Почему в Хроме каждая закладка является отдельным процессом? Потому что это фича? Нет. Потому, что не получается сделать так, чтобы он не падал. Кроме того, Win32 процесс (и в x86 и в x64 ОС) может адресовать максимум 2ГБ, а учитывая прожорливость сегодняшних браузеров это не так уж много. Вот и разнесли по процессам.
И совсем не по тому что это “лучше”. Аргумент про “падает только одна закладка” - не аргумент.

Моё личное мнение: GIL - это громадный костыль, который не даёт питону/пайтону оторваться от того же PHP. Лёгкий, удобный, функциональный, кроссплатформенный, с адекватной отладкой и тд. Но GIL напрочь убивает возможность использования многопоточности.

PooH
Я имею ввиду всякие файловые дескрипторы, семафоры, объекты GDI и прочая и прочая, они же выделяются процессу и удаляются им или за ним.

А я подумал, что имеется в виду ядро процессора. Вот и написал, что процесс напрямую с процессором не взаимодействует и что этим занимается операционная система. Когда процесс один, то его потоки нельзя положить на разные ядра процессора, а когда процессов несколько, то они раскладываются по ядрам процессора.

То же самое написано и здесь.

The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

JOHN_16
Пользуюсь я ФайрФоксом и на современных “тяжелых” страницах я постоянно наблюдаю картину когда Лиса просто фризится при открытии новой вкладки, на 2-5 секунд.

Я помню ещё древние Opera и Netscape (предпочитал), где были вкладки, которые грузились независимо от других. То есть во время просмотра одной вкладки не нужно открывать другую, чтобы она загружалась, потому что она загружалась в фоне.

То, что Firefox падает, - так они его переписали на Java, а там всё падает. Сейчас он очень тормознутый стал, я уже задумался о переходе на что-нибудь более быстрое (реализованное на C++).

py.user.next
То, что Firefox падает, - так они его переписали на Java

ЩИТО?
А можно пруф?

py.user.next
они его переписали на Java

Если глянуть в исходники, то за исключением упоминаний про андроид список java файлов такой:

linux:/tmp/mozilla-release # find -iname “*.java” | grep -v android
./parser/html/javasrc/MetaScanner.java
./parser/html/javasrc/Portability.java
./parser/html/javasrc/AttributeName.java
./parser/html/javasrc/UTF16Buffer.java
./parser/html/javasrc/Tokenizer.java
./parser/html/javasrc/TreeBuilder.java
./parser/html/javasrc/HtmlAttributes.java
./parser/html/javasrc/ElementName.java
./parser/html/javasrc/StateSnapshot.java
./parser/html/javasrc/StackNode.java
./python/mozbuild/mozbuild/test/backend/data/test-manifests-package-tests/not_packaged.java
./build/mobile/robocop/Driver.java
./build/mobile/robocop/RoboCopException.java
./build/mobile/robocop/FennecTalosAssert.java
./build/mobile/robocop/FennecNativeElement.java
./build/mobile/robocop/FennecNativeActions.java
./build/mobile/robocop/Assert.java
./build/mobile/robocop/StructuredLogger.java
./build/mobile/robocop/FennecNativeDriver.java
./build/mobile/robocop/LaunchFennecWithConfigurationActivity.java
./build/mobile/robocop/Element.java
./build/mobile/robocop/RobocopShare2.java
./build/mobile/robocop/Actions.java
./build/mobile/robocop/FennecInstrumentationTestRunner.java
./build/mobile/robocop/PaintedSurface.java
./build/mobile/robocop/RobocopShare1.java
./build/mobile/robocop/FennecMochitestAssert.java
./build/mobile/robocop/RobocopUtils.java
./build/annotationProcessors/utils/AlphabeticAnnotatableEntityComparator.java
./build/annotationProcessors/utils/GeneratableElementIterator.java
./build/annotationProcessors/utils/Utils.java
./build/annotationProcessors/SDKProcessor.java
./build/annotationProcessors/AnnotationInfo.java
./build/annotationProcessors/classloader/AnnotatableEntity.java
./build/annotationProcessors/classloader/JarClassIterator.java
./build/annotationProcessors/classloader/IterableJarLoadingURLClassLoader.java
./build/annotationProcessors/classloader/ClassWithOptions.java
./build/annotationProcessors/AnnotationProcessor.java
./build/annotationProcessors/CodeGenerator.java

Jar архивов столько

linux:/tmp/mozilla-release # find -iname “*.jar” | grep -v android
./modules/libjar/test/unit/data/test_bug370103.jar
./dom/tests/mochitest/whatwg/postMessage.jar
./dom/base/test/file_bug804395.jar
./dom/base/test/file_bug945152.jar
./dom/html/test/bug392567.jar
./dom/security/test/cors/file_CrossSiteXHR_inner.jar
./config/tests/test.manifest.jar
./toolkit/mozapps/extensions/test/addons/test_install4/badaddon.jar
./toolkit/mozapps/extensions/test/addons/test_install4/addon5.jar
./toolkit/mozapps/extensions/test/addons/test_install4/addon7.jar
./toolkit/mozapps/extensions/test/addons/test_chromemanifest_3/inner.jar
./toolkit/components/telemetry/tests/search/searchTest.jar
./toolkit/components/search/tests/xpcshell/data/searchTest.jar
./xpcom/tests/regorder/extension2.jar
./build/mobile/robocop/robotium-solo-4.3.1.jar
./docshell/test/bug369814.jar

Какие из этого выводы можно сделать - что парсер HTML написан на Java. Но можно ли сказать что прям FireFox переписан на нем? ну..наверное нет

Забыл ссылочку на исходник https://archive.mozilla.org/pub/firefox/releases/41.0/source/