Re: lug-bg: Задачка Закачка: Bash

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Tue, Nov 30, 2004 at 12:06:54PM +0200, Aleksandar Valchev wrote:
> Да, exec-а преебава простотията. Вместо exec сложих system(). Със system()
> май върви по-добре, накара ме да си рестартирам PC-то (като се има на
> предвид, че няма никакви limits).

Още по-добре ще върви с fork(), както няколко души ти казаха, макар че и
system() не е много зле - това, че изисква един допълнителен процес - самия
shell - може и да не е толкова лошо като за fork-бомбичка.

> Мисля си, че е по-добре да се ловят сигналите SIGKILL, 
> SIGSTOP (да не може да се спре изпулнението, чрез kill), но чрез системното 
> извикване signal(), не става. В ман page на signal() пише, че може да 
> игнорираш или да хванеш всички сигнал изключение на SIGKILL и SIGSTOP, като 
> същото се отнася и за sigaction (евала на Linux :) ). 

Не толкова Linux, колкото първоначалните дизайнери още на AT&T Unix, още в
Bell Labs.  Това, че НИКОЙ процес не може по НИКАКЪВ начин да спре SIGKILL и
SIGSTOP, си е основна парадигма във всички операционни системи, които
поддържат някакъв подобен механизъм за комуникация между процеси чрез
подаване на сигнали.  Не можеш, и това е - live with it :)

> Не мисля, че трябва нещо да пишеш в buffer-a за да зеeма памет. Би трябвало 
> malloc() да заделя памет и тя си остава заделена, без значение дали си 
> записал нещо в нея или не :). Якото е, че не се освобождава :).

Не е точно така.  Това много зависи 1. от реализацията на malloc() в libc
или в приложението (има някои програми, които използват собствени версии на
malloc()) и 2. от реализацията на system calls brk() и sbrk().  Ако искаш,
потърси из мрежата или из mailing lists информация за 'malloc overcommit'
или 'memory overcommit', за да видиш, че има много случаи и доста
операционни системи, които дават с malloc() и sbrk() доста повече памет,
отколкото системата наистина има, и я разпределят чак когато процесите
наистина поискат да пишат в нея - и да, Linux по принцип също прави така,
както вече беше казано в тази нишка :)

Поздрави,
Петър

-- 
Peter Pentchev	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am the thought you are now thinking.

Attachment: pgpJZtuy56puJ.pgp
Description: PGP signature