🚀 go-pugleaf

Dnia 26-11-2007, Pn o godzinie 09:17 +0000, Sektor van Skijlen pisze:

> No dobrze - ale co taki sygnał może przerwać?

Stan blokowania sygnałów przez dany wątek ma postać pary (all, async),
gdzie all jest liczbą naturalną oznaczającą liczbę powodów, dla których
sygnały powinny być zablokowane, a async ma zakres 0..1. Ta przestrzeń
stanów daje to tylko trzy możliwe reakcje na sygnały:

(0, 0) - sygnał może być obsłużony w każdym momencie
(0, 1) - sygnał może być obsłużony tylko przez wybrane operacje,
         które na coś czekają (tzw. tryb synchroniczny)
inne   - sygnał jest kolejkowany do obsłużenia później

Stan blokowania jest jawnie zmieniany przez pewne funkcje, a także mniej
jawnie:

- Sygnały są blokowane na czas wzięcia muteksu, wzięcia read-write locka
  (jak on się po polsku nazywa?), obliczania wartości leniwej zmiennej,
  inicjalizacja modułu innego niż moduł główny, jawnego uruchomienia
  finalizatora obiektu, obsługi wyjątku (chyba że zaznaczono inaczej),
  obsługi sygnału.

- Konstrukcja zarządzająca zasobem wymagającym jawnego zwalniania
  (Using) składa się z trzech części: pobranie zasobu, treść główna
  i zwolnienie zasobu. Na czas pobierania zasobu asynchroniczne
  sygnały są blokowane, a na czas zwalniania - wszystkie są blokowane.

- Nowy wątek normalnie ma odblokowane sygnały, ale można utworzyć wątek
  z zablokowanymi na starcie (co jest konieczne, jeśli chcemy uniknąć
  okienka, kiedy wątek nie zdążył jeszcze określić innej funkcji obsługi
  sygnałów).

(Leniwa zmienna to jest coś takiego, co przy pierwszej próbie odczytania
wartości wykonuje dane obliczenie, a przy następnej próbie zwraca to co
obliczono poprzednio. Pytanie o wartość leniwej zmiennej, która właśnie
się liczy przez inny wątek, czeka na zakończenie tego obliczenia.
Pytanie o wartość leniwej zmiennej, która właśnie się liczy przez ten
sam wątek, jest błędem. Inicjalizacja modułu ma analogiczną semantykę
i wewnętrznie używa jednej leniwej zmiennej na moduł.)

Operacje, które obsługują sygnały w trybie synchronicznym, to
czekanie na condition, na zakończenie wątku, na zakończenie procesu,
na wejście-wyjście (w tym na otwarcie pliku, który może być rurką -
wtedy open jest blokujące), na upływ danego czasu. Ale nie na mutex,
na leniwą zmienną ani na finalizator obiektu.

Nie będę teraz wnikać w bardziej szczegółowe przypadki: leniwe listy
(które są podobne do leniwych zmiennych, ale mają dodatkowe komplikacje
związane z sygnałami), eksperymentalne kolejki multipleksujące zdarzenia,
czekanie na muteks przy wyjściu z lokalnego zwolnienia, a nie przy
wejściu na lokalne zajęcie, fork wielowątkowego procesu i inne.

> Oczywiście wątek nadrzędny powinien dostać killa w przypadku wykrycia
> zakleszczenia.

Jakiego zakleszczenia i jaki wątek nadrzędny? W Kogucie wątki nie mają
relacji nadrzędny-podrzędny.

Jeśli wątek miałby zakleszczyć się sam ze sobą, to odpowiednia operacja
rzuca wyjątkiem. Wzajemne zakleszczenie kilku wątków nie jest wykrywane,
ale są reakcje na to, że wątek miałby zostać odśmiecony (co może być
skutkiem ich zakleszczenia, jeśli nikt inny nie ma dostępu do obiektów
synchronizujących, na których czekają) i na zakleszczenie wszystkich
wątków.

> Tak - tu, jak najbardziej, ale napisałem wyraźnie: NIE odkładanie
> reakcji na przerwanie ad calendas graecas.

To jest kwestia przyzwoitości kodu, a nie gwarancji dawanych przez język.
Dobrym zwyczajem jest blokowanie sygnałów tylko na krótkie chwile, ale
nie da się tego wymusić.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/