> 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
