Board.KolibriOS.org

Считаю, что, возможность убить неугодный процесс должна быть у любого пользователя. И диалог должен показываться всем. Другое дело что ОС "должна понимать":
1. что делает тот или иной процесс в данное время.
2. как поступать в конкретной ситуации.
и 3. у ос должна быть возможность безопасно завершать повисшее приложение. Без завершения работы ОС и с сохранением данных.
Колибри ведь позиционируется как надёжная ОС для встраиваемых систем?! Или нет?

Pathoswithin wrote:А, так это не баг, а фича... Тогда скажу, что она обходится открытием и закрытием другой программы (например, ctrl-alt-del).

неудачная шутка юмора.

Тогда скажу, что она обходится открытием и закрытием другой программы (например, ctrl-alt-del).

У меня это не сработало, и ОС благополучно зависла.

*после того, как она зависла. Хотя, у меня тоже не всегда работает. Зато теперь знаю, из-за чего это происходит после ошибки в драйвере ФС.

0CodErr wrote:Насколько помню, CleverMouse сделала защиту от убийства процесса, который не завершил файловую операцию(вроде так, если, не ошибаюсь). И может, как раз в этот момент он зависает.

Почти. Защиту от убийства процесса, который занят любым системным вызовом. За исключением тех, которые явно говорят, что они безопасны, вызовом unprotect_from_terminate - сейчас это 5, 10, 23.

Leency wrote:Именно. Я считаю, что это не правильно. Должен быть диалог вроде: "Убивать процесс не завапренренвапке вапер кепркеер. Вы уверены что хотите это сделать?"
В крайнем случае, такая функция должна быть для разработчиков, которые знают, что делают.

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

Pathoswithin wrote:А, так это не баг, а фича... Тогда скажу, что она обходится открытием и закрытием другой программы (например, ctrl-alt-del).

Достаточно дождаться завершения системного вызова. Защита не блокирует убийство, она его просто откладывает до безопасного момента. Если системный вызов не завершается - то это баг в системном вызове, его надо чинить.
Кроме того, защита не работает против смерти от внутреннего кровотечения.

Mega_Myr wrote:Другое дело что ОС "должна понимать":
1. что делает тот или иной процесс в данное время.
2. как поступать в конкретной ситуации.
и 3. у ос должна быть возможность безопасно завершать повисшее приложение. Без завершения работы ОС и с сохранением данных.

Ну вот ОС ровно это и делает. Завершать приложение в середине системного вызова небезопасно, нужно ждать.

Mega_Myr wrote:Колибри ведь позиционируется как надёжная ОС для встраиваемых систем?! Или нет?

Нет. Колибри позиционируется как маленькая десктопная ОС.

Mega_Myr wrote:Если открыть WebView и нажать на одну из двух ссылок, то он тут же виснет. И никак не убивается.

Зависание было из-за бага в сетевом стеке. После r6710 зависать больше не должно.
P.S. Я не сказала, что оно должно работать.

WebView c r6690 по r6710 падает при запуске. И починка сетевого стека ему не помогла. =] P.S. Может выпилить его? Всё равно пользы ноль.

Выпилим как только ты запилишь новый.
Сколько свободной ОЗУ у виртуальной машины?

Было 128мб. Поставил 256 - вылеты прекратились. А не жирно обрубку памяти?! Windows 2000 c Opera 11 256мб. за глаза. Можно и 128мб. обойтись:
видео

P.S. Я в курсе, что у винды преимущество, в виде файла подкачки. Но это ничего не меняет.

Well, 200 Мб со старта кушать нехорошо, однако пока так.

CleverMouse wrote:

Mega_Myr wrote:Если открыть WebView и нажать на одну из двух ссылок, то он тут же виснет. И никак не убивается.

Зависание было из-за бага в сетевом стеке. После r6710 зависать больше не должно.
P.S. Я не сказала, что оно должно работать.

What exactly seems to be the problem here?

After hovering WebView edits are not observed, with approximately revision 6685. Instead, he fell. As it turned out from the lack of memory. Now (r6711, may be before), it does not go on the links: Web page is not available.

Spoiler:

Снимок.PNG (85.42 KiB)

Web page is not available Viewed 8921 times

P.S. You can not fix what is broken initially. Therefore, I will no longer run the Webview and write error, so that you "patch" does not accidentally broke Network.

Mega_Myr wrote:Мою "проблему" можно считать условно-решённой:
Браузер перестал виснуть и позволил выйти в сеть, когда я переключил тип подключения в настройках виртуальной машины (VirtualBox 5.1.8r111374) с NAT на сетевой мост. Из-за нехватки знаний глубже копать не стал.

Это регрессия в реализации NAT в VirtualBox 5.0.28 и 5.1.8. Вот этот баг. В свежих тестовых сборках они его уже исправили. Либо откатись на 5.0.26 или 5.1.6, либо поставь свежую тестовую сборку VirtualBox, либо не используй NAT.
Про размер памяти Leency уже отписался.
Кроме того, с r6709 до r6722 включительно были проблемы с резолвингом имён хостов в IP-адреса. В r6723 всё должно работать - при условии, что выполнены два предыдущих пункта, которые не связаны с нашими багами.

В r6723 сеть работает. NAT не использую. С учетом всех пунктов, браузер тоже работает.

#6724 by leency in /programs/cmm: WebView and draw_buf.h: show error notification if requested memory size is more than free RAM size

Решил я немного браузер подтянуть.

WebView 1.55
В целом за последние версии:
- исправлено много багов, тем самым улучшена стабильность
- ускорено отображение страницы
- увеличены элементы интерфейса

WebView 1.56
- исправлена обработка тега <pre>
- исправено определение содержить документ html тег или нет
- большой шрифт в меню