Fix examples requesting thread closure from within same thread

[gemenerik]

70e6f7d closes IncomingPacketHandlerThread upon link closure. This changed behavior for examples that close the link from within IncomingPacketHandlerThread callbacks - previously these threads remained open (leading to duplicates being created), now they close immediately. This PR updates the examples to use a flag-based approach to avoid issues with threads closing themselves.

[Copilot]

Pull Request Overview

This PR fixes a threading issue where examples were attempting to close the IncomingPacketHandlerThread from within its own callbacks, which became problematic after a recent change that closes this thread upon link closure. The solution implements a flag-based approach to defer the actual link closure until the main thread can handle it safely.

• Replaces direct close_link() calls in callbacks with a flag-based mechanism
• Adds polling logic in main loops to check the disconnect flag and close the link from the main thread
• Simplifies the flash-memory.py example by removing the complex signal-based termination approach

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
examples/parameters/basicparam.py	Adds disconnect flag and defers link closure to main thread
examples/memory/write-ow.py	Adds disconnect flag and defers link closure to main thread
examples/memory/write-eeprom.py	Adds disconnect flag and defers link closure to main thread
examples/memory/read-eeprom.py	Adds disconnect flag and defers link closure to main thread
examples/memory/flash-memory.py	Replaces signal-based termination with flag-based approach and removes unused import
examples/memory/erase-ow.py	Adds disconnect flag and defers link closure to main thread

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The else clause on the for loop will execute when the loop completes without breaking, meaning the timeout occurred. However, if flasher.should_disconnect becomes True on the last iteration, the loop will break but flasher.disconnect() won't be called. Consider moving the timeout disconnect logic outside the loop or handling this case explicitly.

Suggested change

	else:
	if not flasher.should_disconnect:

[ataffanel]

10 seconds is very conservative. I am not sure it is necessary to add code for a potential race on the last 0.5 second.

[ataffanel]

Works for me! Fixes the threads problems.