From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <515b2b3a3bd91e7fd9b7e7e78d03deed@quanstro.net> To: 9fans@9fans.net From: erik quanstrom Date: Sun, 23 Nov 2008 16:51:11 -0500 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] bug in rio: unhiding deleted windows Topicbox-Message-UUID: 51129cc8-ead4-11e9-9d60-3106f5b1d025 > situation, maybe this could be added to /sys/src/cmd/rio/rio.c: > > : ruda; diff rio.c rio.c_orig > 683c683 > < if(hidden[i] != nil) unhide(i); > --- >> unhide(i); > : ruda; > > This usually helps, but it neither solves much, nor it is 100 % sure > it saves you. The problem, as I see it now, is more difficult. > > Rio apparently stores a list of hidden windows in > Window *hidden[100] > Should this list couldn't change when playing with rio's menus, things > would be easy. But it can (the hidden window in our example exits). > And, generally, it can possibly change in any way. To underline this > fact, note that even on one single line like mine > if(hidden[i] != nil) unhide(i); the problem is that the fs proc and the keboard thread both fiddle with the the hidden array. in the style of rio, the solution would be along the lines of sending a message (say) the keyboard thread to hide the window. since windows have unique ids, sending a message like "hide 72" would be unambiguous. acme has similar problems that tend to show up on laggy connections. > In this view I feel the whole thing is just flawed. I appologise to > the authors, if I am wrong. i didn't write rio. saying the "whole thing is just flawed" is a bit over the top. you've identified a concurrency bug that isn't fatal. if it bothers you, then please fix it. we'd be appreciative. > But it definitely disappointed me, along > with limitations like that 100 static allocation size (and there are > more). I'd like to see a system _without_ any such static things in > spite of the fact you probably will never have so many hidden windows. why? i don't think it makes sense to say static sizes are unequivicablly bad. static allocation has advantages. it's simplier and less error prone, and there are no concurrency considerations. there are always tradeoffs. and in this case, i fail to see the advantage of allowing more than 100 hidden windows so if anything, i would only wonder why the limit was so high. > I consider it a good & only right way how it should be done today. i think you need to make a case for this and explain how you would handle concurrent access to allocated structures. keep in mind that realloc can move things around. - erik