🚀 go-pugleaf

Dnia 22-11-2007, Cz o godzinie 08:30 +0000, Sektor van Skijlen pisze:

> W praktyce to oznacza, że w którymś momencie MUSISZ po prostu
> najzwyczajniej w świecie obsłużyć ten wyjątek i nie ma od tego
> ucieczki.

W którymś momencie tak, ale lepiej nie przy każdym sleepie osobno,
tylko zbiorczo w głównej funkcji wątku.

> > Mam rozumieć, że lepiej, kiedy sprzątanie przez wątek po jego przerwaniu
> 
> Stop! Nie mówimy tutaj o przerwaniu wyjątku. Mówiłem o zrobieniu sleep.

O przerwaniu wątku, a nie wyjątku. Sleep jest jedną z funkcji,
która reaguje na przerwanie wątku z zewnątrz (Thread.interrupt).
Stąd możliwość InterruptedException.

Nie należy pisać tak jak napisałeś (połykać InterruptedException).
http://www-128.ibm.com/developerworks/java/library/j-jtp05236.html

Pewnym odpowiednikiem tego w SUS są funkcje, które są przerywane przez
pthread_cancel w stanie PTHREAD_CANCEL_DEFERRED + PTHREAD_CANCEL_ENABLE
(domyślnym zresztą):
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

Jedno i drugie jest raczej sztuczką niż porządnym projektem językowym.
Ponieważ te języki nie dostarczają mechanizmów pozwalających
programiście informować, w których momentach można przerwać wątek,
domyślnie zakłada się, że można to zrobić wtedy, kiedy wątek na coś
czeka (ale nie na mutex). Bo po pierwsze jest szansa, że takie momenty
będą zdarzały się wystarczająco często, a po drugie jest szansa, że
wszelkie niezmienniki globalnych struktur danych będą wtedy zachowane.

Różnica między Javą a Uniksem polega w tym miejscu na tym, że Java
zmusza programistów do zauważenia, że dana funkcja jest przerywalna,
a Unix nie. W połączeniu ze sprawą odśmiecania powoduje to, że
w Uniksowym C/C++ pthread_cancel ma małe szanse poprawnego działania.
Większość programistów nawet nie wie, że taka funkcja istnieje, i nie
pisze kodu tak żeby działał poprawnie w obliczu asynchronicznych
przerwań.

Zgadzam się, że checked exceptions powodują z reguły więcej kłopotu niż
pożytku, ale z tego nie wynika, że jest w nic samo zło.

> To, że w Javie funkcja sleep() jest metodą klasy Thread to tylko taka jej specyfika.

Nieważne, jakiej metody jest klasą. Ważne, że pozwala na
InterruptedException. Metoda Object.wait też jest przerywalna,
chociaż nie jest metodą klasy Thread.

> Bo jeśli mówimy o normalnym przerwaniu wykonywania się wątku, to
> w takim razie powinien on teoretycznie wystąpić w dowolnym momencie.
> Nie tylko jak się wykonuje sleep().

Gdyby mógł wystąpić w zupełnie dowolnym momencie, to nie dałoby się
pisać poprawnego kodu, bo np. nie da się zagwarantować, że z pewnych
dwóch instrukcji wykonają się obie albo żadna.

Należy umożliwić wątkowi blokowanie przerywania oraz zintegrować
automatyczne blokowanie z innymi konstrukcjami języka (większość
programistów nie myśli o możliwości przerwania wątku i tego nie
zmienimy). Jeśli się postarać, jeśli język ma szansę rozpoznać
regiony, które muszą się wykonać w całości, w sposób niewymagający
od programisty dużego zachodu, to można domyślnie dopuścić przerywanie
w dowolnym momencie.

Przy czym w C++ nie ma na to szans, bo jest zdecydowanie zbyt wiele
miejsc, których nie można przerwać, ale nie ma jak ich automatycznie
rozpoznać. Na przykład region między new a przypisaniem gołego wskaźnika
do sprytnego wskaźnika nie może być przerywalny (przynajmniej przy
standardowym alokatorze).

> > > Natomiast "łatwe języki" zwykle dają złudzenie łatwości tematu w przypadku
> > > trudnych zagadnień. Jednym z takich trudnych zagadnień jest wielowątkowość.
> 
> > Dawałyby takie złudzenie gdyby ułatwiały projekt, który z pewnych
> > subtelnych powodów jest niepoprawny, w porównaniu do poprawnego
> > projektu, który miałby trudniej z winy języka. Ale nie przypominam
> > sobie takich cech różnych języków, więc nie wiem, co masz na myśli.
> 
> Same wątki w Javie już wystarczą. Nadużywa się ich, zamiast zrobić to samo na
> włóknach.

Uważasz, że lepiej wprowadzać sztuczne utrudnienia w używaniu wątków,
żeby zniechęcać do nich programistę?

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