А память? А 40 процессов (для некоторых > 30-40 закладок - это нормально)? Не, это мнимая безопасность. Хотя, кому что нравится, наличие альтернативы это всегда хорошо.
А память будет тратиться вне зависимости от того, что используется, процессы или потоки, т.к. память тратится не на структуры данных, связанные с многпроцессой моделью, а на содержимое страниц. Тут есть один нюанс - при многопоточной модели часть памяти разделяемая, и лики в одном потоке могут привести к ликам во всем броузере до момента его завершения. При многопроцессовой модели память легко освобождать просто завершением процесса, хотя есть и более продвинутые методы.
Для тех, кому 40 вкладок - это нормально, процессы также будут полезны, поскольку при повисании броузера придется закрывать только одну вкладку, а не весь броузер (неудобство от переоткрытия 40 вкладок очевидно).
Идея "каждой вкладке по процессу" - утопия, в Windows® создание процесса обходится дороже, чем в привычной к этому unix, особенно, если система загружена.
На собственно создание процесса тратится ничтожное время по сравнению с тем, что потратится на загрузку и рендеринг страницы в новооткрытом табе.
Цитата
Удобство снятия зависшей страницы без прибивания всего "браузера"? Во-первых, этого не нужно допускать изначально ("Security by Correctness")
По хорошему да, но у Firefox никак не получается избавится от проблемы утечек памяти, хотя над этим активно работают. Во вторых есть внешние плагины, качество которых разработчики не могут проконтролировать. Очевидный пример - флеш, часто именно он роняет броузер. Вот его крайне полезно было бы держать в отдельном процессе и изолированно, чтобы в случае глюков перегружать и не перезапуская броузер.
Сорцы доступны, 450 мб тарбол или около гига напрямую.
Цитата(alexk @ 3 Сентября, 2008, 12:59)
лики в одном потоке могут привести к ликам во всем броузере до момента его завершения
То есть, вместо того, чтобы не допускать утечек памяти, ты считаешь, что лучше просто изолировать "текучий" код в отдельный процесс? Впрочем, вопрос не требует ответа, т.к. он очевиден из архитектуры и философии unix
Цитата(Fireball @ 3 Сентября, 2008, 14:27)
но у Firefox никак не получается избавится от проблемы утечек памяти
Firefox не единственный браузер А насчёт флеша согласен, держать его как рендер в изолированной среде неплохой вариант, хотя лично я как-то не сталкивался с завешиванием браузера или какими другими его проблемами.
То есть, вместо того, чтобы не допускать утечек памяти, ты считаешь, что лучше просто изолировать "текучий" код в отдельный процесс? Впрочем, вопрос не требует ответа, т.к. он очевиден из архитектуры и философии unix
Если у нас надежный, проверенный и рабочий способ "изначально не допускать утечек памяти", программируя на С или С++ - готов о нем послушать.
Цитата
Ну, собственно, о чём и говорилось: изоляция этоне панацея, а утопия из-за кажущейся безопасности
О том, что это не утопия, говорит ряд проектов. в которых изоляция процессов работает, к примеру PostgreSQL. Видимо в гугле ее реализовали недостаточно хорошо, т.е у них нет надежного механизма завершения сбойного процесса и продолжения работы. Без знания того, от чего произошла ошибка сложно делать какие-либо выводы.
Если у нас надежный, проверенный и рабочий способ "изначально не допускать утечек памяти", программируя на С или С++ - готов о нем послушать.
Есть некоторые обвертки, классы для этого, но они слишком простые и в более сложных ситуациях практически бесполезны. Дедушкины способы поседелок с дебагерами актуальны всегда, valgrind неплох в своем роде.
Есть некоторые обвертки, классы для этого, но они слишком простые и в более сложных ситуациях практически бесполезны. Дедушкины способы поседелок с дебагерами актуальны всегда, valgrind неплох в своем роде.
Это не способ "изначально не допускать утечек памяти, это способ минимизировать ущерб от них, о чем я говорил выше. Способ "изначально не допускать утечек памяти" - это такой же идеализм, как и "способ изначально не допускать ошибок".
valgrind для отлова мемликов я использовал всего один раз и остался недоволен - на большом проекте, в котором уже применены способы "минимизации ущерба" он практически бесполезен и за массы ложных срабатываний.
Никто не слышал - анонсирует ли гугл появление отладчика своего JS V8
Имхо, воопсче они засланцы... Вместо стандартизации броузеров, развития KHTML (ну и бонусы к сервисам своим за спонсорство соотвесно), они погнали свой броузер. Новый движок, новые глюки, новый геморой верстальщикам и js девелоперам. Собсно пока я ничего существенного для пользователей не заметил кроме продвижения гуглом своих сервисов. Эдак и yahoo с рамблером и тд могут свои движки выпустить и тд. Добрая воля гугла - не более чем коммерческий ход. На кой ляд спрашивается они два года разрабатывали что то, если не хотели на этом деньги делать.
ЗЫ Как я слыщал более 60% доходов firefox foundation - это строчка поиска гугла по умолчанию у FF, стартовая страница с логотипом FF в гуглах и прочие мелочи. Теперь интересно что дальще будет в отнощениях FF-google? Как это скажется на дальнейшем развитии FF?
exn Лучше в программе пользоваться не обычным malloc/free, а оберткой, которая позволит в случае чего освободить более одного участка выделенной памяти. И пользоваться MALLOC_CHECK (http://www.gnu.org/software/libtool/manual/libc/Heap-Consistency-Checking.html). Ну и понятно функции вида strncpy и strncmp вместо strcpy и strcmp.
Тем временем мозилле некогда отвлекатся на всякие там хромы. From the B* Slap dept.: На данный момент мы заняты исправлением ошибок, повышением стабильности и производительности, работаем над альфа версией TraceMonkey... может быть нам переименовать TraceMonkey в V10 ?
alexk Я понял. Я думаю вы как опытный в этом деле человек не будете отрицать что бяка может случится, иногда вместо полного анализа кода хочется воспользоватся valgrind, который я соглашусь не идеален. Какой инструмент используете вы для отлова утечек? Или только путем медитаций ?