> Zadanie 6. Najpowszechniej implementowane wątki przestrzeni jądra wprowadzają do programów dodatkowy stopień złożoności. Co dziwnego może się wydarzyć w wielowątkowym procesie uniksowym gdy:
> * wołamy funkcję fork, aby utworzyć podproces
> * użytkownik wciska kombinację «CTRL+C» i w rezultacie jądro wysyła «SIGINT» do procesu
> * czytamy w wielu wątkach ze zwykłego pliku korzystając z jednego deskryptora pliku
> * modyfikujemy zmienną środowiskową funkcją [putenv(3)](http://man7.org/linux/man-pages/man3/putenv.3.html)
> * wątki intensywnie korzystają z menadżera pamięci z użyciem procedury malloc

* fork:
    niektóre operacje mogą być krytyczne, nieatomowe i chronione mutexem. W forku mamy wtedy w połowie przetworzone dane. Dziecko ma tylko jeden wątek. Cieżko a nawet niemozliwe powiedzieć co robiły inne wątki i co zrobić żeby dane były znowu spójne. Stan mutexa jest niezdefiniowany - zalezny od implementacji: może np. być zablokowany w dziecku jeśli był zablokowany w ojcu - mamy przesrane jeśli inny wątek (nie ten od forka) miał akurat mutex.
* SIGINT:
    tylko jeden wątek dostaje sygnał. Jeśli wątek miał złą maskę sygnału, to może on zostać zignorowany (bo maska jest lokalna względem wątku) {chyba ?}.
* 1 deskryptor:
    plik ma coś takiego jak 'kursor' - który jest wykorzystywany w read() i write() - wiele wątków może przesunąć kursor, bo skorzysta z offsetu z deskryptora a nie lokalnego względem wątku. Przez to możemy w jednym wątku przeskoczyć ileś bajtów i mieć złe dane. Ogólnie to to jest undefined behaviour w POSIXie (tak przynajmniej kojarzę - ale fajnie by było znaleźć wiecej info)
    > The read() function shall attempt to read nbyte bytes from the file associated with the open file descriptor, fildes, into the buffer pointed to by buf. The behavior of multiple concurrent reads on the same pipe, FIFO, or terminal device is unspecified.
* putenv(3) - jest oznaczony jako not thread-safe, może być tak, że jeden wątek robi putenv(string), ale procedura umieszcza w środowisku tylko wskaźnik na tego stringa (dlatego stosuje się albo statycznego albo mallocowanego) Jeśli jakiś wątek zmienia w jakiś sposób tego stringa NIE PRZEZ PUTENVA, wtedy w różnych wątkach mozemy mieć różne wartości.
    > The putenv() function shall use the string argument to set environment variable values. The string argument should point to a string of the form "name= value". The putenv() function shall make the value of the environment variable name equal to value by altering an existing variable or creating a new one. In either case, the string pointed to by string shall become part of the environment, so altering the string shall change the environment. The space used by string is no longer used once a new string which defines name is passed to putenv().
* malloc - używa drobnego albo żadnego blokowania(w zależności od konfiguracji) z wykorzystaniem globalnego mutexa, więc każda operacja malloc w innym wątku czeka na odblokowanie mutexa żeby móc się wykonać. W przeciwieństwie do tcmalloca od Googla, który to ma mutex na odpowiednie kubełki pewnych rozmiarów, w związku z czym można wykonywaćkilka malloców naraz. Przez globalny mutex mamy bardzo częste blokowanie operacji malloc, więc i alokowanie miejsca podczas działania programu będzie musiało czekać. wtedy albo będziemy mieli strasznie zcinający program, albo dostaniemy out of memory jeśli nie ma zaimplementowanego spamowania malloc do skutku. No to ogólnie duże spowolnienie na wydajności programu.