From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8146d476679d5cc0450451d5b26dfc09@quanstro.net> From: erik quanstrom Date: Wed, 26 Nov 2008 15:55:24 -0500 To: 9fans@9fans.net 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: 5327a6c0-ead4-11e9-9d60-3106f5b1d025 > 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? yes they are unique for all time. (per rio.) >> acme has similar problems that tend to show up on laggy connections. >what actually happens? the mouse, keyboard and screen may be out-of-sync for a short time. > > 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. it's deeper than that. if you do dynamic allocation in any language you need to recover from the case that there is no memory. > 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. fancy algorthims are slow when n is small. n is usually small. why hash something that is going to be a small number? > > there are no concurrency considerations. there are always tradeoffs. > I can't see what you mean by concurrency considerations. :( assignment of a shared pointer must consistent in all processes with access. thus some sort of atomic update or locking mechanism must be used. - erik