aboutsummaryrefslogtreecommitdiff
path: root/ch23/23_a_3.hs
diff options
context:
space:
mode:
authorJan Sucan <jan@jansucan.com>2025-09-14 21:46:33 +0200
committerJan Sucan <jan@jansucan.com>2025-09-14 21:46:33 +0200
commitf01b5a8122bd5135ee984ba2c1c25fc3c833c5f6 (patch)
treea71b37752597585235445dc37eb8b13f02289c06 /ch23/23_a_3.hs
parent9d89965b0661d1968151d9b646148b6a71209705 (diff)
23_a_3: Add solution
Diffstat (limited to 'ch23/23_a_3.hs')
-rw-r--r--ch23/23_a_3.hs17
1 files changed, 17 insertions, 0 deletions
diff --git a/ch23/23_a_3.hs b/ch23/23_a_3.hs
new file mode 100644
index 0000000..c8e808b
--- /dev/null
+++ b/ch23/23_a_3.hs
@@ -0,0 +1,17 @@
+-- Why does guiFetch combine worker functions instead of calling statusWindow
+-- twice?
+
+
+-- The most important reason is: Considering how the operations are implemented,
+-- updating the podcast and downloading its episodes need to be run sequentially
+-- in that order because the downloading can produce expected results only when
+-- it knows the latest information about the podcast's episodes.
+--
+-- Calling statusWindow twice would run those operations concurrently and their
+-- execution ordering could not be predicted. For example, the downloading could
+-- be run before the updating.
+--
+-- Other than that, the statusWindow uses the same GUI status window. The latter
+-- call to it would overwrite information from the former call, replacing the
+-- callback for canceling the child thread. Then it wouldn't be possible for the
+-- user to cancel the first thread.