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

[erik quanstrom <quanstro@quanstro.net>]

> situation, maybe this could be added to /sys/src/cmd/rio/rio.c:
>
> : ruda; diff rio.c rio.c_orig
> 683c683
> < 		if(hidden[i] != nil) unhide(i);
> ---
>> 		unhide(i);
> : ruda;
>
> This usually helps, but it neither solves much, nor it is 100 % sure
> it saves you. The problem, as I see it now, is more difficult.
>
> Rio apparently stores a list of hidden windows in
>     Window *hidden[100]
> Should this list couldn't change when playing with rio's menus, things
> would be easy. But it can (the hidden window in our example exits).
> And, generally, it can possibly change in any way. To underline this
> fact, note that even on one single line like mine
>     if(hidden[i] != nil) unhide(i);

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.

acme has similar problems that tend to show up on laggy connections.

> In this view I feel the whole thing is just flawed. I appologise to
> the authors, if I am wrong.

i didn't write rio.  saying the "whole thing is just flawed" is a bit
over the top.  you've identified a concurrency bug that isn't fatal.
if it bothers you, then please fix it.  we'd be appreciative.

> But it definitely disappointed me, along
> with limitations like that 100 static allocation size (and there are
> more). I'd like to see a system _without_ any such static things in
> spite of the fact you probably will never have so many hidden windows.

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
there are no concurrency considerations.  there are always tradeoffs.  and
in this case, i fail to see the advantage of allowing more than 100 hidden
windows so if anything, i would only wonder why the limit was so high.

> I consider it a good & only right way how it should be done today.

i think you need to make a case for this and explain how you would
handle concurrent access to allocated structures.  keep in mind that
realloc can move things around.

- erik