I have a Tkinter/ttk app that analyzes packets arriving every 10-25 ms.  My present implementation uses a thread that updates 30 StringVars after every socket read, then calls update_idletasks() to update the corresponding Entry widgets.  My app crashes no more than 30 minutes after starting.
Searches revealed that Tk isn't really thread-safe, and I have two main choices:

Use a thread + queues.
Use a function + .after(1, function).

The UI does little more than start/stop the updates, and provide the Entry widgets for display.
The primary wait in the system is the socket read, which has a timeout of 2x the expected packet rate (so it can't block forever).
In this case, would you prefer approach #1 or #2?
I'm leaning toward #2 for its simplicity, but I'm not sure if there are any Tk gotchas waiting along that path.  I'll probably try both while I await the community wisdom.
My personal rule of thumb is to avoid threads unless they are strictly required. Threads add complexity. Plus, there's a large percentage of programmers who aren't particularly thread-savvy, so threads add an element of risk if this program will be used or maintained by others. 
That being said, in this particular case I think I'd go with thread + queues. Since you know how often the display should update, I'd set up a poll of the queue for every 10ms or so to update the widgets.
Real-time Tkinter/ttk Entry widget update: thread+queue or .after(1)?