Исходное сообщение
"Дискуссия об использовании языка C++ для разработки ядра Lin..." Отправлено Аноним, 15-Янв-24 22:45
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле. > Речь про кучу, если вдруг проблемы с чтением В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно. Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется. > Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны > железа самая топорная У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? > А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот > и хрен, это проц аппаратное исключение кинул на самом деле. >> Речь про кучу, если вдруг проблемы с чтением > В ней в конечном итоге тоже - память либо выделят, либо при > левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите > (т.е. по дефолту) это не сильно лучше стека ибо де факто > аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. > Связано с тем что многие программы заказывают намного больше памяти чем > реально юзают, и это позволяет на доступном RAM нафоркать сильно больше > процессов, соответственно. > Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее > нет - у вас *alloc вроде прокатил но это как бы > и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела > это не распостраняется. >> Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны >> железа самая топорная > У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.
	Введите код, изображенный на картинке: