Dan Haffey 2acf161381 Cursor spinner while processing events for more than 500ms. (#599) ... The spinner is a simple |/-\ at the current cursor position. For non-terminal events, the root of the event's wire is also displayed to the right of the spinner to give some indication of what's causing an unresponsive terminal. I used the simplest synchronization strategy I could think of: u3_utat.mex_u is a mutex that serializes access to a terminal's state. The main thread holds it at all times except when processing events. When a terminal receives a %bee blit with a non-nul bulb (the event ovum), it releases the mutex to let the spinner thread do its thing. A %bee with a nul bulb halts the spinner by grabbing the mutex and refreshing the input line. Off-thread console writes are directly against the underlying fd to avoid trashing non-thread-safe libuv state. Given the simple locking pattern, calling libuv from the spinner thread might be fine, but I didn't feel like auditing vere to rule out concurrent calls. It worked when I tried it, but... threads. I didn't look into supporting anything other than the main terminal, so currently it's the only one that receives %bee blits. In daemon mode, the spinner is disabled entirely and no additional thread is started.		2015-12-12 20:42:33 -08:00
..
vere.h	Cursor spinner while processing events for more than 500ms. (#599)	2015-12-12 20:42:33 -08:00