|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey I Zavilohin 2:5020/400 22 Jan 2002 18:07:47
To : vitus@ice.ru
Subject : Re: "Hоpмальный"
--------------------------------------------------------------------------------
vitus@ice.ru <vitus@ice.ru> wrote:
> ZK>Своп этот нужен только на "крайний случай" - если что-то толстое вдруг
> ZK>память сожрало, чтобы его можно было корректно завершить и машина не
> ZK>встала раком. По моему опыту - линуксовые програмы в большинстве своем
> ZK>совершенно не способны обрабатывать ситуацию нехватки памяти. Такое
> ZK>впечатление, что программисты вообще не проверяют успешность выделения
> ZK>памяти.
> Вопрос в том, кто виноват - язык C, в котором нет нормального
> механизма exceptions или учителя программирования, которые учат
> пользоваться стандартными функциями C как процедурами, не проверяя кода
> завершения. Впрочем malloc это все равно функция как не крути.
> С другой стороны большинство программ обрабатывают неуспешность malloc
> одним единственным способом - perror("malloc");exit(1); А это как раз
> то, чего тебе, насколько я понимаю, хотелось бы избежать.
> Вообще - интересная идея - блокирующий malloc - если памяти нехвата,
> он делает sleep на несколько секунд (или если это блокинующий sbrk, то
> до первого освобождения памяти) и потом повторяет операцию. А NULL
> возвращает только при убийстве сигнала.
> По-моему, такой malloc практически заменяет swap по NFS - программы
> смерть которых ты называешь "система раком встала" будут просто тихо
> ждать пока им память отдадут.
А причем тут malloc? Витус ты как будто не знаешь как оно там у нас
унутре 8-))))
Если люди обработчик сигнала написать не могут - то тут им никакой
блокирующий малоок (кстати хых - вернет ли он когда-нть 0 в случае
нехватки памяти под линуксом?) не поможет.
--
To invent, you need a good imagination and a pile of junk.
-- Thomas Edison
--- ifmail v.2.15dev5
* Origin: EMS JSC News Server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
