diff options
| -rw-r--r-- | README.md | 2 | ||||
| -rw-r--r-- | ch23/23_a_3.hs | 17 |
2 files changed, 18 insertions, 1 deletions
@@ -186,7 +186,7 @@ are prefixed with 'Module_'. | 19_b_3 | yes, in 19_b_2 | | | | **_23_a_1_** | yes | 529 | 23. GUI programming with gtk2hs| | 23_a_2 | yes, in 23_a_1 | | | -| 23_a_3 | | | | +| 23_a_3 | yes | | | | **_24_a_1_** | | 542 | 24. Concurrent and multicore programming | | 24_a_2 | | | | | **_24_b_1_** | | 551 | | 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. |