---
title: SO Lista 3
tags: SO
author: Mateusz Reis
---

# SO LISTA 3

## Zadanie 1
- Wady fork():
- **nie jest już prosty** - specyfikacja wyróżnia 25 specjalnych przypadków jak kopiować pamięć rodzica np. timery, w dodatku na zachowanie forka wpływa wiele flag takich jak *DONTFORK* - nie udostępnianie obszaru pamięci dla dziecka
- **fork jest kiepską abstrakcją** - przez duplikowanie pamięci rodzica użytkownik musi sam wypisać cały bufer IO aby uniknąć podwójnego wypisania tej samej treści
- **fork nie jest thread-safe** - dziecko otrzymuje tylko jeden wątek i jest możliwa niespójność pamięci z rodzicem - przykładowo jeden wątek rodzica nałoży blokadę na stertę, inny wywoła fork, wtedy dziecko może czekać na zdjęcie blokady które nigdy nie nastąpi (malloc nie jest bezpieczny w połączeniu z fork)
- **fork nie jest bezpieczny** - dziecko dziedziczy wszytskie uprawnienia po rodzicu i to programista jest odpowiedzialny za usunięcie wszytskich rzeczy, których dziecko nie potrzebuje
- **fork jest powolny** - wywołanie forka może trwać bardzo długo np. w Chrome zajmuje to nawet 100ms
- **fork prowadzi do przesadnej alokacji pamięci** - gdy duży proces wywołuje fork tworzone jest wiele mapowań pamięci, które nigdy nie zostaną użyte

- Fork - jest wygodny dla małych procesów nie zużywających dużej ilości pamięci

- posix_spawn() - używany do stworzenia procesu-dziecka, który wykonuje określony w argumencie wywołania plik. Jest połączeniem forka i exec z paroma usprawnieniami. Jednak nie został stworzony aby je zastąpić i dostarcza tylko pewien podzbiór ich funkcji. Spawn po wywołaniu forka i przed wywołaniem exec wykonuje szereg akcji zdefiniowanych przez argumenty wywołania np. ustawia maskę sygnałów, zamyka deskryptory, tworzy sesję itp. Pozwala to uniknąć wiele problemów wymienionych powyżej. Przede wszytskim znacznie skraca to czas wykonania, który nie jest już zależny od rozmiaru pamięci rodzica.

## Zadanie 2
#### Po zabiciu basha rodzicem sleepa staje się systemd - domyślny menadżer systemu i usług dla Linuxa

- Proces staje się **osierocony** gdy jego rodzic skończy swoje działanie
- zadanie **drugoplanowe** - zadanie które działa w "tle", można je przywrócić komendą *fg*

#### Gdy wyślemy SIGHUP bash kończy działanie powłoki i sleepa. Dzieje się tak ponieważ:

>The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

>strace -s trace=signal bash
>sleep 1000&
>ps -efj
>kill -s 9 [pid]
>ps -efj

## Zadanie 3

- **terminal** - środowisko do wprowadzania/czytania tekstu
- **zadanie pierwszoplanowe** - zadanie, które może czytać i pisać do/z terminala
- **wstrzymanie procesu** - sygnał SIGSTOP
- vi jest zainteresowany obsługą SIGSTOP oraz SIGCONT tylko kiedy jest programen pierwszoplanowym