Różne są sposoby programowania asynchronicznego. Stosuje się wątki, przetwarzanie porcjami, delegację do osobnych procesów i jeszcze kilka innych technik. Zakładając, że w danym przypadku wydzielamy pewną operację asynchroniczną do osobnego procesu (załóżmy, niech to będzie kompresja), należy mieć nad tym zadaniem pewną kontrolę. Jak można to zrobić?
Najprostszym wyjściem wydaje się być rozwiązanie oparte na callbackach (w tej czy innej formie) - uruchamiamy operację i, gdy konieczne jest powiadomienie, otrzymujemy odpowiedź. Jest to też rozwiązanie najczęściej stosowane, mimo to ma kilka wad, które należałoby usunąć.
Przede wszystkim: takie rozwiązanie eliminuje możliwość uruchomienia zadania według reguły "odpal i zapomnij". Skoro tak - lepszym rozwiązaniem, niż osobny proces, byłoby uruchomienie osobnego wątku wewnątrz tego samego procesu. Mniejszy narzut komunikacji i lepsze zgranie z aplikacją - a wady są te same. Inna sprawa: co, gdy uruchamiana tak aplikacja zostanie brutalnie zakończona? Brak powiadomienia, a więc i brak informacji "co się tam dzieje" (wyjątkiem są systemy promujące taką formę komunikacji).
Jak więc rozwiązać delegowanie zadań z zewnątrz? Pisząc coś, co wykonuje asynchroniczną operację dla innego procesu, zezwólmy na sprawdzanie stanu. Jeśli użytkownik chce po prostu "żeby coś się stało", uruchamia nasz proces i przestaje się nim interesować. Jeśli chce mieć informacje na temat jego przebiegu - po prostu sprawdza stan (lub ustawia "nasłuch" na zmiany wspomnianego - forma dowolna, zależna od systemu operacyjnego). Dzięki temu istnieje możliwość kontroli wykonywanej operacji, a jednocześnie zyskujemy opcję użycia "fire&forget". Skoro dobrze jest w obu przypadkach - rozwiązanie bliskie jest perfekcji :)
Brak komentarzy:
Prześlij komentarz