From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 26 Nov 2008 20:52:10 +0100 From: "Rudolf Sykora" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <515b2b3a3bd91e7fd9b7e7e78d03deed@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <515b2b3a3bd91e7fd9b7e7e78d03deed@quanstro.net> Subject: Re: [9fans] bug in rio: unhiding deleted windows Topicbox-Message-UUID: 53214302-ead4-11e9-9d60-3106f5b1d025 > 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. What do you mean by unique ids? I think it is not enough to have a unique id at just one instant. We need a unique id for a qualitatively long time (i.e. infinite). It seems to me that numbers in /dev/wsys do not get reused, which would be just wanted, but is it really so? > acme has similar problems that tend to show up on laggy connections. what actually happens? > 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 It's simpler in C, because dynamic allocation in C is a pain. If I were writing a window manager in say python, I wouldn't think about any allocation problems, I guess. I would just make a dictionary of windows hashed by a window's id and that would just work. Maybe I only have a very distorted view on it. I've never programmed anything like that. > there are no concurrency considerations. there are always tradeoffs. I can't see what you mean by concurrency considerations. :( Ruda