В списке рассылки разработчиков браузерного движка WebKit
представлен (https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...) проект WebKit2 (http://trac.webkit.org/wiki/WebKit2), в рамках которого планируется перейти на многопроцессную модель работы, при которой обработка разного web-контента (выполнение JavaScript, парсинг HTML, вывод на экран) производится в изолированных друг от друга процессах. Технология изоляции в WebKit2 очень близка по своей сути к методам, реализованным в браузере Google Chrome и отличается главным образом лишь тем, что модель разделения обработки по разным процессам будет встроена непосредственно во фреймворк, давая возможность использовать данную технологию во всех построенных на базе WebKit браузерах.
<img src="http://www.opennet.me/opennews/pics_base/26159_1270822038.jp... align=right style="border-style: solid; border-color: #e9ead6; border-width: 5px;" title="структура WebKit2" border=0>В браузерах на базе WebKit2 часть движка, отве...URL: https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...
Новость: http://www.opennet.me/opennews/art.shtml?num=26159
распределение всё по процессам -- это АКТУАЛЬНЕЙШАЯ задача современных програм!вот только как они буду портировать это на Windows ? тамже сплошником только и принто использовать "Нити" ("Threads")... (а в данный момент времени -- "Нити используются" всё чащще стали использоваться не для увеличения производительности, а для задания НЕ_ЛИНЕЙНОЙ логике работы алгоритма)
...так как -- тут и к гадалке не ходи -- нужно использовать КЛОНИРОВАНИЕ процессов (системный вызов 'fork(...)')
вообще-то fork (и vfork) в линухе реализованы через системный вызов clone. отличие только в параметрах передаваемых clone.
более того, в линухе для обеспечения многопоточных приложений используются облегчённые процессы.другими словами, разница в линухе между процессами и потоками размыта настолько, насколько это возможно. а параметры clone таковы, что между "потоком" и процессом есть ещё целый ряд вариантов.
в общем, в то, что что-то там распухнет я не верю. вернее точно знаю, что это не так.
ну я не такой спец в ядре .. даж и не знал что есть функция clone(..)когда писал про клонирвоание -- как раз и имел ввиду fork(..) семейство :-)
> в общем, в то, что что-то там распухнет я не верю. вернее точно знаю, что это не так.
ну я тож думаю что не расспухнет сильно. а если и распухнет -- то во благо производительности и надёжности.
я хотел затронуть тему портирования на windows... как там дела у Windows с fork(...) ?(только если не рассматривать в Windows -- специальную posix-подсистему, которая используется чутьли только не в лабораторных целях, и которая не во всех версиях Windows)
не просто функция. системный вызов.
функция в ядре - do_fork.
и это семейство не только по работе с процессами, но и с потоками.
>ну я тож думаю что не расспухнет сильно. а если и распухнет -- то во благо производительности и надёжности.если действительно продумают этот момент, то может даже уменьшится.
>я хотел затронуть тему портирования на windows... как там дела у Windows с fork(...) ?ну значит я не дорасказал - обычно для всей этой батвы используется библиотека-посредник.
если такая библа будет и для винды (а она будет. и уже есть. и уже не одна), то проблем - скомпили и используй.
Ну так и не пишите про fork(2), а читайте про ps(1) :) Там есть целый раздел THREAD DISPLAY. А потом посмотрите на тот же firefox через полученный таким образом бинокль.
>>как там дела у Windows с fork(...) ?да всё так же, вызов функции с одиннадцатью параметрами, шесть из которых -- структуры... венда же ж...
А что на счет OpenMP, или все забыли про него?
ну вообще-то для параллельного программирования используют именно нити (pthread.h) в адресном пространстве одного процесса, то есть просто параллельные функции http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h....клонирование процессов с помощью fork() используется в основном для запуска иного процесса с exec()
>ну вообще-то для параллельного программирования используют именно нити (pthread.h) в адресном пространстве
>одного процесса, то есть просто параллельные функции http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h....
>
>клонирование процессов с помощью fork() используется в основном для запуска иного процесса
>с exec()как раз таки я и хотел скахать что применение нитей (posix_threads) -- сейчас используют НЕ для увеличения производительности. а только для усложнения логики программы (например сделать некий процесс асинхронным, в случае если его компонент УЖЕ имеет только синхронный интерфейс. или наоборот)..
..раньше -- да -- Нити (pthreads) использовали для увеличения производительности.. (было дело -- не спорю)
....а сейчас -- принято использовать сборшики мусора (сложные модели данных с цеклическими зависимостями -- как могут обойтись без сборщика мусора?) , который блокируют сразу ВСЕ нити (одного процесса) при своей деятельности.
....также принято использовать и другие всевозможные мьютексные блокировщики.. другими словами в сложных много-нитевых программах -- в текущий момент времени ЗАЧАСТУЮ выполняется только одна нить!
а всё это -- потомучто нити общаются между собой через общие данные (а не через каналы (pipe) ) , поэтому и происходится использовать постоянную синхронизация через блокировки.
(ято конешно понимаю что у каждого низкоуровневого компонента/класса -- может быть свой независимой мьютекс (или несколько) . но чем больше разных мьютексов -- тем больше вероятность неправильной архитектуры приложения и врезультате чего -- появления вероятности "Взаимоблокировки" ("Deadlock") . да и с множеством мьютексами -- не факт что мы не будем постоянно вызывать блокировку многочисленных Нитей (pthreads) в тех или иных местах программы...)
выход из решения проблемы -- процессы! (ктото выше -- называл слово "потоки". но дабы не путать "потоки" и с "потоками <iostreams>" не буду употреблять это слово)процессы работают каждый в своём адресном пространстве и не блокируются изза постоянных блокировок нитей других процессов. а обмен данными через каналы (pipe) который ещё и обладает некоторым буфером -- НЕ ВЫЗЫВАЕТ излишние блокировки при обмене состоянием!
>....а сейчас -- принято использовать сборшики мусора (сложные модели данных с цеклическими зависимостями -- как могут обойтись без сборщика мусора?) , который блокируют сразу ВСЕ нити (одного процесса) при своей деятельности.глупости.
это вообще компромисс между признанием "да, я пишу кривые проги" и хоть какой-то стабильностью кода типа - "ну она же не жрёт больше, чем есть в этой системе?"
и к потокам/процессам не имеет отношения.
всё сказанное - полная чушь, имеющая отношение только к реальности оратора
фантазер... :)либо у Вас богатая фантазия на благодатной почве обрывочных знаний, либо Вы так умело издеваетесь над местной публикой
pthread.h - это всего лишь заголовочный файл POSIX-совместимой библиотеки, использующей облегчённые процессы (в том числе и линухе). в любом случае, они оперируют теми же системными вызовами, но на более высоком уровне.
примеры POSIX-совместимых библ - LinuxThread, NTPL, NGPT...
>pthread.h - это всего лишь заголовочный файл POSIX-совместимой библиотеки, использующей облегчённые процессы
>(в том числе и линухе). в любом случае, они оперируют теми
>же системными вызовами, но на более высоком уровне.
>примеры POSIX-совместимых библ - LinuxThread, NTPL, NGPT...В смысле, что нет разницы между процессом и нитью? Насколько я знаю, каждый процесс имеет по крайней мере одну нить (main thread). Если нитей несколько, то они существуют в одном адресном пространстве и разделяют ресурсы процесса и могут выполняться параллельно; в чём и смысл.
fork() же порождает именно новый процесс со своим адресным пространством, который обычно заменяется с помощью exec(), что является намного более дорогим. Во всяком случае в Darwin pthreads основаны на mach threads
Сейчас смотрел исходники fork(), и кроме копирования ресурсов и много чего прочего, происходит создание нити дочернего процесса. Ну это на Mac OS X / Darwin
>В смысле, что нет разницы между процессом и нитью?разница в деталях. не больше и не меньше.
>fork() же порождает именно новый процесс со своим адресным пространством,я уже писал как работает fork (и как работает clone). не вижу смысла повторятся.
зы:
раньше ядро вообще не предполагало поддержку многопоточности. потоки создавались на пользовательском уровне (например при помощи библиотеки pthread). для ядра же все эти ветви выполнения были одним процессом.
сейчас используются облегчённые процессы. всё остальное - это структуры в пользовательском пространстве, реализованные по стандарту POSIX или нет.
ззы:
прочитайте уже про облегчённые процессы. тогда не будете глупости писать
в Mac OS X нет понятия облегчённого процесса, киньте ссылку - скажу спасибо;
на низком уровне (mach) есть tasks и threads, и многопоточность была изначально,
да не собираюсь я вам что-либо кидать! :D
речь шла про винды и линух. и местами про POSIX потоки. ах, вы захотели про мак? ну, хотеть не вредно.
зы:
главное помнить, что потоки - это абстрактные структуры и цпу до них нет дела. в отличие от процессов. ну а если вы точно хотите поговорить о потоках в маке, то внимательно прочитайте вот эту документацию:
>Threads are one of several technologies that make it possible to execute multiple code paths concurrently inside a single application. Although newer technologies such as operation objects and Grand Central Dispatch (GCD) provide a more modern and efficient infrastructure for implementing concurrency, Mac OS X and iPhone OS also provide interfaces for creating and managing threads.http://developer.apple.com/mac/library/documentation/Cocoa/C...
и далее по тексту. :D
Cпасибо за ссылку ;-) но я её само собой читал. И где там сказано, что процессы и нити почти неразличимы? Читаем:The term thread is used to refer to a separate path of execution for code.
The term process is used to refer to a running executable, which can encompass multiple threads.
The term task is used to refer to the abstract concept of work that needs to be performed.Кроме того, там написано, что создание отдельных процессов намного затратнее, чем нитей в одном процессе.
где написано? в устаревшей документации к признанной ими же устаревшей технологии :D
вы хотели услышать, что в маке потоки устарели? яблочники и сами это не скрывает.
теперь вы наверное захотите услышать, что процесс создания процессов тоже у них претерпел изменения? ну так да. вот только терминология осталась.:D
будете меня и дальше потчевать устаревшими сведениями? увольте.
Что устарело? Насколько я знаю все multithreading API основаны на much threads, просто Carbon сейчас выводится из употребления, соответственно и Carbon Thread Manager, Multiprocessor Services.абстрактно:
Нить - это поток исполняемых иструкций
Процесс - это исполняемая программа, состоящая из данных и нитей.Контейнер и начинка не могут быть одним и тем же, или нет?
контейнер, начинка... всё это абстрактные понятия.
спуститесь на уровень ниже и посмотрите, что происходит в реальности - если ядро не поддерживает потоки (т.е. не происходит заполнения соответствующих структур ядра), то при выдаче одним из потоков блокирующего системного вызова ядро вынуждено блокировать весь процесс (со всеми потоками), т.к. ядро банально не знает кто из них это сделал и как это разрулить. (вот она, мистификация потоков - в теории всё класно, а на практике нет)
соответственно для решения этого и ввели облегчённые процессы (это термин ядра), который один в один напоминает поток (всё работает в одном адресном пространстве и т.д.). параллельно с этим что облегченный процесс, что вообще процесс создаются одним системным вызовом clone, а параметры этого вызова ещё и варьируются.
в случае с обычным процессом происходит всё тоже самое, но когда процесс меняет (только в этот период) какие-либо данные (пишет в память), то при записи копируется изменённая страница памяти (COW) и никаких доп. расходов. это всё вкратце.
библы (такие как posix thread) это знают и уже использует вовсю.
почему эти библы не знают об этом в маке, и почему они там теперь названы устаревшими - ну догадайтесь.:D
>[оверквотинг удален]
>и т.д.). параллельно с этим что облегченный процесс, что вообще процесс
>создаются одним системным вызовом clone, а параметры этого вызова ещё и
>варьируются.
>в случае с обычным процессом происходит всё тоже самое, но когда процесс
>меняет (только в этот период) какие-либо данные (пишет в память), то
>при записи копируется изменённая страница памяти (COW) и никаких доп.
>расходов. это всё вкратце.
>библы (такие как posix thread) это знают и уже использует вовсю.
>почему эти библы не знают об этом в маке, и почему они
>там теперь названы устаревшими - ну догадайтесь.:Dclone() есть лишь в Linux, почему вы меряете по ней? Darwin использует микроядро Mach, которое изначально знало о нитях и, насколько я знаю, и умею читать исходники, эти понятия означают там именно то, что означают.
Спасибо, что пояснили ситуацию с Linux, я понял вашу мысль, но применимо к Mach это разные понятия. Что ничуть не мешает использовать ленивое копирование процессов и прочие прелести. Я конечно могу ошибаться и если что, напишу.
да при чём тут clone? (к слову, от mach'а там мягко говоря мало что осталось. собственно кроме message что? гугл как говорится в помощь)
понятия - это только понятия и не более.
в конце концов именно процессор (аппаратная архитектура) определяет возможности, а не наоборот. а возможности его сейчас таковы, что грань между процессами и потоками размылась очень сильно. и новость тому подтверждение. да и где этот гипердтэйдинг? всё больше мультикоре. а ведь там (на мультиядрах) также есть траблы именно с потоками (в классическом смысле). и если в маке облегчённые процессы назовут потоками - то так тому и быть.
зы:
просто с clone и облегчёнными процессами (а это уже стандарт в терминологии *никс. и ввели изначально в солярке кстати) и объяснять проще, да и грамотней.
согласитесь, если мак не сможет использовать такой мощный инструмент, как cow/mmap/etc (которые основаны на страничном управлении памятью), то это будет как-то глупо.
собственно они уже натянули поверх своих новых механизмов (согласно той же доке из того же урл) лайер к посикс потоками. так что старые проги достаточно просто перекомпилить.
ззы:
и не путайте создание процесса (execv) и его клонирование (fork/clone). первый действительно более дорогостоящий, хоть и использует тот же форк.
от mach там много чего, в том числе и потоки - mach thread и оно не куцое, а изменённое и расширенное:- untyped interprocess communication (IPC)
- remote procedure calls (RPC)
- scheduler support for symmetric multiprocessing (SMP)
- support for real-time services
- virtual memory support
- support for pagers
- modular architectureпроцессы называются tasks, потоки - threads, и именно mach их реализует, всё остальное - есть врапперы.
забыл сказать, что на Mac принято использовать fork() только вместе с exec(), и лучше заменять эту пару на posix_spawn().
http://developer.apple.com/mac/library/documentation/Darwin/...
всё это понятно, но я ещё раз пытаюсь сказать, что мы говорим о разных вещах.
есть куча библиотек реализующих многопоточность. в том числе и на smp, и распределённых на кластер, и т.д.
но всё это уровнем выше. и с разной степенью качества и функциональности.
примеры ну ОЧЕНЬ крутых библиотек - openmp, tbb от intel.я же говорю о базовых вещах. системных вызовах, которые только создают базу для подобных вычислений. и fork/vfork/clone - это НЕ элементы таких библиотек. это системные вызовы (функции ядра. работающие в кольце 0), которые вы можете использовать сами или через посредника, такие как выше (если они умеют всем этим пользоваться в полном объёме).
зы:
ну а перечисленные вами ipc/rpc/(что_там_ещё?) - вообще совсем не в кассу.
я лишь написал о том, что процессы и потоки реализованы на уровне Mach именно отдельно, как функции, манипулирующие соответствующими структурами, а всё, что выше - есть врапперы: posix threads, NSThread, fork(), etc. Кроме того, мне написали разработчики, что каждая нить в userlevel имеет back-end нить ядра. Иными словами: если вы в Mac создаёте нить, скажем, с помощью класса NSThread или pthread, то микроядро Mach запускает mach thread.Если ядро BSD работает поверх микроядра Mach, это значит, что системные вызовы BSD написаны с использование системных вызовов Mach. Конечно, можно было реализовать многопоточность на уровне BSD или userlevel, это было бы хорошо для быстрого создания процессов / потоков, но было бы неэффективно управлять ими (вы сами об этом написали выше).
Я просто перечислил то, чем занимается Mach.
ну а я "перечислил" как это легко, непринужденно и эстетично решается (при помощи 1-го системного вызова) в линухе. :Dзы:
>что каждая нить в userlevel имеет back-end нить ядра.вот-вот.
накладные расходы неизбежны.
> распределение всё по процессам -- это АКТУАЛЬНЕЙШАЯ задача современных програм!Да, знакомый чувак открыл в хромиуме 150 табов. Система начала тормозить, список задач засрался процессами а суммарное потребление памяти сделало FF в несколько раз. Актуально, мля, особенно когда это уродство и в FF сделают - будет на что поюзать 8 гигз оперативы, блин ;(
Память - расходный материал. Не жалко. А вот нагрузку на процессор что хром, что огнелис неслабую дают. Что очень критично на мобильных железках.
> Память - расходный материал. Не жалко.Расскажи это сисадминам, админящим сетки на тонких клиентах. Запасись предварительно зелёнкой и бинтами ;)
Любой расходный материал
- когда-нибудь кончается
- может пригодится для более важных вещейС таким подходом возвращаемся во времена DOS - может работать только одна задача - недобраузер типа хрома или недософт на java. Все, памяти больше нет - расходный материал, хренли.
Блин, а я вот пользуюсь Firefox 3.7 и в нем отключил этот mozilla-runtime, так как он жутко тормозил браузер.
>> распределение всё по процессам -- это АКТУАЛЬНЕЙШАЯ задача современных програм!
>
>Да, знакомый чувак открыл в хромиуме 150 табов. Система начала тормозить, список
>задач засрался процессами а суммарное потребление памяти сделало FF в несколько
>раз. Актуально, мля, особенно когда это уродство и в FF сделают
>- будет на что поюзать 8 гигз оперативы, блин ;(везде есть свои минусы :-(
...бывает приходиться осознанно жертвовать чемто.
может оно так и хорошо в FF...
..может показаться......но ведь -- по сути -- каждый сайт (вкладка с сайтом) -- это отдельная программа(?). разве по смыслу -- это не так(?)
мы же не жалуемся что --
"почему при открытии Gajim и emerge -- открывается ДВЕ копии процесса python? для уменьшения потребления ОЗУ -- моглибы и открывать в двух нитях ОДНОГО процесса!"
...так как ясно что разные программы нада "отделить"
>мы же не жалуемся что --Уважаемый, почитайте про mmap(2) и cow (copy-on-write), а потом -- лучше через год-два -- Ваши слова на эту тему не будут вызывать смех, пропорциональный квадрату их количества.
Ну чесслово, не надо.
ну не надо так строго то.
сегодня он что-то (надеюсь) для себя открыл. завтра (надеюсь) "мы" будем с ним советоваться.
прочитал, спасибо!..вобщемто знал про mmap(...) и раньше но использовать в приклодных программах не приходилось (так как ограничение на 2~4 гигобайта для x86-компютеров -- это слишком мало)
, но прочитать лишний раз посмотреть man -- конешно же никогда не помешает :-)говояр про mmap(...) вы наверно намекаете на то что при открытии исполняемого файла (и shared_object_библиотек) -- они НЕ копируются в память, а только mmap-яться(?)
ну тык я нигде и не говорил что они копируются? и даже не намекал! зачем мы вообще затронули тему mmap(...)? фраза "открытие процесса" и "копирование файлов в память" -- помоему явно не синонимы.
или вы чтото другое имели ввиду? если проясните -- то будет хорошо. :-)
далее про cow (copy-on-write) .
говоря про механизмы cow -- вы наверно имеете ввиду -- что когда производиться fork(...) -- МГНОВЕННОЕ_копирование всего состояния fork`нутого процесса -- на самом деле НЕ производиться. а производиться только "ленивое" копирование (тоесть только тех (и только тогда) областей памяти которые начинают изменять после fork(...) в дочернем клоне )
...и ещё вы наверно имели ввиду то что ПОВТОРНО исполняемые файлы (и shared_object_файлы) не mmap(...)-яться, а даётся толко новое адресное пространство на уже за`mmap`енный области.
(( например при открытии gajim и потом emerge ))
ну и что из этого? при чём тут cow ? зачем было поднимать тему cow ?
да... конешно... НИКТO НЕ СПОРИТ(!) что "mmap" и "cow" -- ускоряют процесс открытия нового процесса: повторно не производяться рутинные операции по запуску исполняемого файла.
но я и не говорил о том что "повторно запускается исполняемый файл" -- я говорил что запускаются "ДВА ПРОЦЕССА(!), а не ДВЕ нити одного процесса".
"процесс" и "исполняемый файл" -- РАЗУМЕЕТСЯ ЧТО это НЕ одно и тоже (даже школьник знает) . например один исполняемый файл (его процесс) -- может пораждать (клонировать) кучу процессов (совершенно не связанных с исполняемыми файлами) -- но от этого НЕ станет производиться каждый раз процедура запуска файла.
когда мы говорим слово "процесс" -- первое что должно приходить в голову это -- "адрессное пространсиво и файловые дескрипторы", а не какието там действия по запуску win-program.exe-файлов .
может я был и неправ в верхних своих сообщениях когда говорил о том что threads уже НЕ используют для увеличения производительности (а только процессы) -- этот момент по крайней мере спортный...
...но вот эти ваши издевательства на тему mmap и cow...
...зачем они были? если хотите чтото КОНКРЕТНОЕ сказать мне -- скажите!
хотите сказать что "при повторном открытии python на самом деле не открывается ПРОЦЕСС, а просто запускается ещё одна НИТЬ по уже открытому процессу" ? ну так так и скажите это! в Windows возможно именно так и происходит. а в unix -- НЕТ НЕ ТАК: Нить и Процесс -- отличаются тем что разграниченны между собой НЕ-общим состоянием (хотя механизмы mmap и cow -- помогают делать это разгроничение -- не очень требовательным к вычислительным ресурсам).
а если не хотите говорить -- ну тык если молчать то конешно выглядеть умнее будете (тоже мне секрет) .
>говояр про mmap(...) вы наверно намекаете на то что при открытии исполняемого
>файла (и shared_object_библиотек) -- они НЕ копируются в память, а только
>mmap-яться(?)Именно.
>ну и что из этого? при чём тут cow ? зачем было поднимать тему cow ?
Эх. При использовании памяти, о котором вообще-то говорили.
>да... конешно... НИКТO НЕ СПОРИТ(!) что "mmap" и "cow" -- ускоряют процесс
>открытия нового процесса: повторно не производяться рутинные операции по запуску
>исполняемого файла.Дело в этом контексте не в ускорении, а в том, что если есть:
* пользователи Вася и Петя
* программки A и B, использующие библиотечку, ну пусть L
-- то запуск каждым из этих пользователей по своему экземпляру обеих этих программок приведёт, грубо говоря, вот к какой картинке использования памяти:* mmap'нутый экземпляр L в r/o
* mmap'нутые бинарники A и B
* rw-шные куски с данными, специфическими для процессов, запущенных Васей и ПетейЕсли же программки слинкованы статически (один из обсуждаемых случаев) либо таскают с собой свои копии (на *nix с ELF можно также почитать про RPATH при желании) -- то к такой:
* mmap'нутые бинарники A и B, каждый из который включает
в своём адресном пространстве копию L
* rw-шные куски с данными пользователейХуже может быть только если каждого из пользователей угораздило поставить ещё и свои экземпляры собранных статически программ (которые находятся в отдельных файлах); тогда реюза памяти, занимаемой кодом, в общем случае не будет (KSM в сторону).
>но я и не говорил о том что "повторно запускается исполняемый файл"
>-- я говорил что запускаются "ДВА ПРОЦЕССА(!), а не ДВЕ нити
>одного процесса".Да-да, я так и прочитал.
>"процесс" и "исполняемый файл" -- РАЗУМЕЕТСЯ ЧТО это НЕ одно и тоже
>(даже школьник знает) . например один исполняемый файл (его процесс)Так всё-таки "даже школьник" или "исполняемый файл (его процесс)"?
>-- может пораждать (клонировать) кучу процессов (совершенно не связанных
>с исполняемыми файлами) -- но от этого НЕ станет производиться каждый
>раз процедура запуска файла.Файлы не "запускаются".
>может я был и неправ в верхних своих сообщениях когда говорил о
>том что threads уже НЕ используют для увеличения производительности (а только
>процессы) -- этот момент по крайней мере спортный...Лучше не говорить о том, в чём плаваешь. Проверено. :)
>...но вот эти ваши издевательства на тему mmap и cow...
>...зачем они были? если хотите чтото КОНКРЕТНОЕ сказать мне -- скажите!Конкретное Вы и сами поймёте, когда почитаете более системно про организацию виртуальной памяти в современных (и даже не особо) ОС. Кажется, и у Робачевского в его довольно доступной книжке по UNIX затрагивалось, хотя точно не помню.
Переписывать книжку глупо, а для внятного и сжатого рассказа мне опыта не хватает. То есть что глупости несёте (и не со зла, просто прочитанное не улеглось) -- понимаю, а объяснить без ссылок на самые основы -- никак.
>хотите сказать что "при повторном открытии python на самом деле не открывается
>ПРОЦЕСС, а просто запускается ещё одна НИТЬ по уже открытому процессу"?Нет.
при которой обработка разного web-контента (выполнение JavaScript, парсинг HTML, вывод на экран) производится в изолированных друг от друга процессах
====
по моему это должен решать разработчик а не framework
Ух-ты, не думал что болт на движке вебкит. А еще удивлялся как это этому бровсеру удалось справиться со страничками лучше чем опера мини.
> а по мере выполнения в WebKit операции, получает специальные уведомления.Бог ты мой, 15 лет прошло, чтобы эти программасты додумались до удобной модели "переиспользования"! Пипец, прогресс... Не удивительно, что до сих пор нет внятного браузера - то дырявые, то медленные, то неуклюжие... что ж за позорники их писали всё это время?
Возможно, над каждым стояли менеджер с маркетологом и вопили наперебой - "Релиз давай! Реклама оплачена! Срок настает! Пофигу качество!"
>15 лет прошло, чтобы эти программасты додумались до удобной модели "переиспользования"!Насколько я понимаю, речь идет, всего лишь, об асинхронном режиме работы отдельных компонентов.
>Unfortunately, the open-source WebKit2 is not yet supported on Linux. Apple has just provided support for Windows and Mac OS XТо есть выпустить тулкит только для макоси и винды(!), но при этом пропустить линукс... так можно было сделать только специально.
apple никогда этого и не делала.
что тут удивительного то?зы:
основной мотив - сделать как в хроме или лучше.
вот и фф туда же движется.
