From b95d581e86ee57de7c163efa5eb0fb165d0a1032 Mon Sep 17 00:00:00 2001 From: Pietro Gagliardi Date: Tue, 18 Mar 2014 11:30:35 -0400 Subject: [PATCH] Update on my locking problem in the README. --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 0574c58..12424ba 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,8 @@ The issue: - because the drawing function is now stuck waiting for the mutex to be unlocked, the label.SetText() system-dependent operation never runs, so the mutex is never unlocked - this fools Go's deadlock detector; it never reports anything - changing from standard mutexes to R/W mutexes does not work -- making resizes concurrent causes resizes to become too slow to be acceptable (they trail behind the actual user resizing by a significant amount) +- making resizes concurrent causes resizes to become too slow to be acceptable: the control resizing doesn't take effect until at least a second after the user lets go, and keeping a grip too long overloads the scheduler with goroutines +- making Label use a goroutine and channels for internal communication did not get rid of the locks If you know a better way I can do things, **please** help... I'm at my wits end here
The main test (`test/test`) now has its label show the current time; GTK+ users can run `test/test -area` for the Area test that sparked this whole calamity.