> 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
