On Sat, 18 Jun 2005 09:30:59 +0200, Michal Kawecki wrote:
> Użytkownik "Piotr Smerda" <piotrs00@go2hell.pl> napisał w wiadomości
> news:1qcgl1ebmuzd9.bhmq9khlnd4r$.dlg@40tude.net...
>> On Sat, 18 Jun 2005 08:12:37 +0200, Michal Kawecki wrote:
>>>>
>>>> A czy opcja ta nie powoduje bezwarunkowego zatrzymania
>>>> aplikacji po przekroczeniu czasu działania tasku czyli w
>>>> praktyce kill?
>>>
>>> A jak inaczej wyobrażasz sobie zamknięcie jakiejś aplikacji?
>>
>> W systemach unix masz całą listę "sygnałów" wysyłanych do
>> aplikacji, np SIGTERM, SIGKILL , SIGSTOP.
>> Jeśli i w Windows da się zaimplementować obsługę i wysyłanie takich
>> sygnałów to wyjście z aplikacji przy odpowiedniej obsłudze mogłoby
>> być mniej "drastyczne" niż kill :)
>
> W Windows też istnieją takie sposoby zamykania aplikacji. Warunkiem
> jest jednak, aby sam zamykany program prawidłowo na nie reagował.
> Wystarczy przyjrzeć się zachowaniu Worda przy próbie jego zamknięcia z
> otwartymi dokumentami, np. poprzez zainicjowanie shutdown systemu. W
> jaki jednak sposób scheduler miałby niby sprawdzać, czy program czasem
> czegoś od niego nie żąda? I w jaki sposób miałby obsłużyć takie
> żądanie? Toż to już nie byłby scheduler, a zaawansowane narzędzie
> skryptowe napisane tylko w celu zamykania poszczególnych, odmiennie
> się zachowujących, aplikacji. . .
>
Echmmm ale to chyba scheduler ma wysyłać np SIGSTOP a program reagować ;)
Scheduler śle SIGSTOP i czeka np 30sek. na odpowiedź. W tym czasie program
który dostaje sygnał, zapisuje co trzeba i zamyka się wysyłając sygnał do
schedulera. I to program ma obsłużyć żądanie poprzez zamknięcie wszystkich
plików i zapis niezbędnych danych.
A po określonym czasie jeśli scheduler nie otrzymałby sygnału typu "ok" po
prostu dawał SIGKILL i po sprawie.
> BTW dobrze napisanej aplikacji kill nie zaszkodzi.
Racja - z tym że takowych niestety jest niewiele.
-- Pozdrawiam PiotrekReceived on Sat Jun 18 15:45:23 2005
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sat 18 Jun 2005 - 16:42:07 MET DST