Re: [9fans] bug in rio: unhiding deleted windows

[erik quanstrom <quanstro@quanstro.net>]

> 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