docs(context-madness): update reamde

context-madness/README.md

@@ -44,8 +44,10 @@ You can input 0 to find out which goroutines are still alive.
 Sample run
 ----------
 
+https://user-images.githubusercontent.com/56697671/232488220-532cd79a-8ce2-4ea7-b3b0-9cc1bb33711e.mp4
+
 Limitations
 -----------
 
 - Since the goroutine getting user input uses `stdin` and the goroutine getting user output uses `stdout`, they share the same windows, so it's difficult to synchronize writing a suggestive message just before the user input, because it might get interlaced with the goroutines printing the output. A solution for that would be, from the main thread, use a channel that notifies when all goroutines that are supposed to stop at one operation have actually stopped (taking into account those who were already stopped previously) and notify the reader goroutine, which is blocked until then. Since the main goroutine receives the signal another goroutine died _at the same time_ with the goroutine stopping through an unbuffered channel, it is guaranteed that at that point the goroutine outputted the message. This should not be that hard to implement but I kindof got bored with it.
-- If sending two kill signals to the same goroutine fast enough, it might be possible to get a panic if the map with the alive goroutines has not been updated before the reader thread sends the signal again. This is highly unlikely, but for completeness can be fixed with the solution mentioned above. Now that I think about it I might just as well do it...
+- If sending two kill signals to the same goroutine fast enough, it might be possible to get a panic if the map with the alive goroutines has not been updated before the reader thread sends the signal again. This is highly unlikely, but for completeness can be fixed with the solution mentioned above. Now that I think about it I might just as well do it...