[9fans] bug in rio: unhiding deleted windows

[9fans] bug in rio: unhiding deleted windows

[andrey mirtchovski]

while looking around for information on the RC strangeness i triggered
a bug with rio: if the last window on the "hidden" stack disappears
_while_ the third mouse button menu is opened, then upon attempting to
unhide the window without releasing the mouse button in between will
result in a read addr fault in 'wunhide()'

here's a stack trace and error message:

acid: lstk()
wunhide(h=0x1)+0x30 /sys/src/cmd/rio/rio.c:1099
	w=0x1768e0
	i=0x0
unhide(h=0x6)+0x27 /sys/src/cmd/rio/rio.c:1129
button3menu()+0x97 /sys/src/cmd/rio/rio.c:686
mousethread()+0x2c4 /sys/src/cmd/rio/rio.c:589
	sending=0x0
	scrolling=0x0
	moving=0x0
	winput=0xdaf40
	xy=0x1f6
	inside=0x1
	tmp=0x0
	w=0xdaf40
	oin=0x929e0
	band=0x1
	r=0xfefefefe

to reproduce:

open a rio window
run "window -hide 'sleep 10'"
click the third mouse button (to bring the "New" menu)
wait 10 seconds (you will know that 10 seconds have passed if you move
the mouse over the last hidden window and the highlighted text appears
to be gibberish)
unhide the last hidden window by releasing the third mouse button
while pointing at it in the menu

if you simply release the third mouse button and bring the menu up
again you will see that the window has disappeared. it is only a bug
when rio isn't given a chance to refresh the third button menu.

cheers: andrey

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

2008/10/8 andrey mirtchovski <mirtchovski@gmail.com>

> while looking around for information on the RC strangeness i triggered
> a bug with rio: if the last window on the "hidden" stack disappears
> _while_ the third mouse button menu is opened, then upon attempting to
> unhide the window without releasing the mouse button in between will
> result in a read addr fault in 'wunhide()'
>
> here's a stack trace and error message:
>
> acid: lstk()
> wunhide(h=0x1)+0x30 /sys/src/cmd/rio/rio.c:1099
>        w=0x1768e0
>        i=0x0
> unhide(h=0x6)+0x27 /sys/src/cmd/rio/rio.c:1129
> button3menu()+0x97 /sys/src/cmd/rio/rio.c:686
> mousethread()+0x2c4 /sys/src/cmd/rio/rio.c:589
>        sending=0x0
>        scrolling=0x0
>        moving=0x0
>        winput=0xdaf40
>        xy=0x1f6
>        inside=0x1
>        tmp=0x0
>        w=0xdaf40
>        oin=0x929e0
>        band=0x1
>        r=0xfefefefe
>
> to reproduce:
>
> open a rio window
> run "window -hide 'sleep 10'"
> click the third mouse button (to bring the "New" menu)
> wait 10 seconds (you will know that 10 seconds have passed if you move
> the mouse over the last hidden window and the highlighted text appears
> to be gibberish)
> unhide the last hidden window by releasing the third mouse button
> while pointing at it in the menu
>
> if you simply release the third mouse button and bring the menu up
> again you will see that the window has disappeared. it is only a bug
> when rio isn't given a chance to refresh the third button menu.
>
> cheers: andrey
>
>
Nice. I tried to follow your instructions and ended up in a situation that
my mouse was movable across my screen, but that was also all I could do...:)
(no menus, no a simple resize/move action) ... reboot with ^t^tr...
(btw. can I do sth. else??! -- in linux one can usually kill X with
alt-ctrl-backspace. Is there anything like that? I hope the underlining
system is just working)
(and one more question: if sth. like this happens on a file server -- I have
a single machine running all --, is it safe to reboot it with ^t^tr? --
usually I use 'fshalt -r'...)
Ruda

[-- Attachment #2: Type: text/html, Size: 2881 bytes --]

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

[andrey mirtchovski]

> (btw. can I do sth. else??! -- in linux one can usually kill X with
> alt-ctrl-backspace. Is there anything like that? I hope the underlining
> system is just working)

you can log in to the node if it allows that and reboot it. i crashed
quite a few drawterm sessions to the same node to make sure it's
repeatable.

> (and one more question: if sth. like this happens on a file server -- I have
> a single machine running all --, is it safe to reboot it with ^t^tr? --
> usually I use 'fshalt -r'...)

that should be fine most of the time. fossil rarely gets angry if you
restart it without halting.

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

[erik quanstrom]

>> (and one more question: if sth. like this happens on a file server -- I have
>> a single machine running all --, is it safe to reboot it with ^t^tr? --
>> usually I use 'fshalt -r'...)
>
> that should be fine most of the time. fossil rarely gets angry if you
> restart it without halting.

"most of the time" is likely dependent on how your
hd(s) cache writes and what part (if any) of the kernel
was trashed before the vulcan nerve pinch.

in other words, if "most of the time" makes you nervous,
it really is a good idea to have a seperate fileserver,
even if it is running a regular kernel.

- erik

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

[Lyndon Nerenberg]

> in other words, if "most of the time" makes you nervous,
> it really is a good idea to have a seperate fileserver,
> even if it is running a regular kernel.

As one who is at this moment trying to extricate himself from a corrupted
FS caused by an 'abrupt' restart, I can highly recommend you pay attention
to Erik's advice.

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

[Russ Cox]

Rather than litter the kernel with special case code,
why not just set up your terminal to listen to the network?
Then if you get in that state again you can drawterm in.

Russ

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

2008/10/11 Russ Cox <rsc@swtch.com>

> Rather than litter the kernel with special case code,
> why not just set up your terminal to listen to the network?
> Then if you get in that state again you can drawterm in.
>
> Russ
>
> Again, I am normally (with my notebook) _NOT_ connected to _ANY_ network.
Yet, I still dare want to be at least able to stop the filesystem when sth.
like that happens again.
(If I can do it elsewhere -- in linux I don't remember the case I could do
nothing -- unless I set and make the keybord unfuctional ...)
Ruda

[-- Attachment #2: Type: text/html, Size: 881 bytes --]

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

[andrey mirtchovski]

> you can log in to the node if it allows that and reboot it. i crashed
> quite a few drawterm sessions to the same node to make sure it's
> repeatable.

i think i meant "kill and restart rio" here, not "reboot the node".

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

i think i meant "kill and restart rio" here, not "reboot the node".


How difficult would it be to add something similar to ^t^tr that would just
killed rio?
Ruda

[-- Attachment #2: Type: text/html, Size: 412 bytes --]

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

[erik quanstrom]

> How difficult would it be to add something similar to ^t^tr that would just
> killed rio?

how about just fixing the bug?

- erik

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

2008/10/10 erik quanstrom <quanstro@quanstro.net>

> > How difficult would it be to add something similar to ^t^tr that would
> just
> > killed rio?
>
> how about just fixing the bug?
>
> - erik


Well, sure. But somehow (don't know exactly how) sth. similar happened to me
lately -- i.e. I ended with not responding rio. And was just thinking: if I
could just kill it... and could not, not having an available shell. Could
not even stop the machine properly (not everybody can have several dedicated
machines, one for a file server, one for a terminal...). I even 'lost' some
of my data then, probably for having to press that ^t^tr and not stop the
filesystem -- one of my files just had a zero lenght after the reboot. To
some it up: I just always feel better when having some possibility to get to
some shell somehow and enter commands... (true, had I set up the files
allowing me to log in from a remote machine, it could have been some
solution then; but this also is not always on hand)
Ruda

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

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

[erik quanstrom]

> Well, sure. But somehow (don't know exactly how) sth. similar happened to me
> lately -- i.e. I ended with not responding rio. And was just thinking: if I
> could just kill it... and could not, not having an available shell. Could
> not even stop the machine properly (not everybody can have several dedicated
> machines, one for a file server, one for a terminal...). I even 'lost' some
> of my data then, probably for having to press that ^t^tr and not stop the
> filesystem -- one of my files just had a zero lenght after the reboot. To
> some it up: I just always feel better when having some possibility to get to
> some shell somehow and enter commands... (true, had I set up the files
> allowing me to log in from a remote machine, it could have been some
> solution then; but this also is not always on hand)
> Ruda

two points
1.  you can run rio in a rio window so you can debug
rio without fiddling with your root rio.

2.  if you're not running the fileserver on your cpu server,
it's always safe to reboot.  in fact, the dozen or so cpu
servers that i manage are rebooted by pulling the plug.
this is one of my favorite features of plan 9's architecture.

i'm not sure why you can't have a dedicated fileserver.
i put mine original fs together for $12.95.  this fs is still
running, i just wanted to put together a diskless fs.

my original fs is a 1998-vintage pIII running 64-bit
kenfs.  the $12.95 was for a 8169s gbe.  i guess i
didn't need to spend that money on the gbe, but i'm a
performance weenie.  it was fast enough for me, but
probablly not for windows.  i'd bet you could find a
number of similar machines for just a few dollars.

if you want new, a via or intel cpu/mobo/video combo
is super cheep.

- erik

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

two points
> 1.  you can run rio in a rio window so you can debug
> rio without fiddling with your root rio.
>

True, but what happened to me was that I did not want to do any debugging. I
wanted to work, i.e. use the computer in the conventional sense -- do sth.
for my school. And you do not usually run rio in rio just for fun in that
case. And then sth. bad happens. And you are ... Actually, this might just
have happened when the bug we're talking about was found -- by chance, it
just happened unexpectedly.
On the other hand, If you know in advance... you run rio in rio. But again,
not my case.
What I am still convinced about is that always having a way to run a shell
is invaluable.


> 2.  if you're not running the fileserver on your cpu server,
> it's always safe to reboot.  in fact, the dozen or so cpu
> servers that i manage are rebooted by pulling the plug.
> this is one of my favorite features of plan 9's architecture.


Yes, I know.


>
> i'm not sure why you can't have a dedicated fileserver
>

It's not a question of money... but thanks for your recommendations. :)
The main reason is I run plan9 only on one of my notebooks (otherwise I use
linux machines since plan9 doesn't have a bit of the software I crucially
need). And I want to be able to work on it, even though it is not at the
moment connected to any network. I need to have my files with me. Is that
enough?

So once more and to conclude, wouldn't it be nice to be able to press
something like ctrl-alt-backspace to, by some means guarantee a way to a
shell?

Ruda

[-- Attachment #2: Type: text/html, Size: 2238 bytes --]

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

[erik quanstrom]

> So once more and to conclude, wouldn't it be nice to be able to press
> something like ctrl-alt-backspace to, by some means guarantee a way to a
> shell?

it would be nicer to fix the bug.  covering it up would be oh so
linux-y.

- erik

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

it would be nicer to fix the bug.  covering it up would be oh so
> linux-y.
>
> - erik
>

Are you sure, it is the last bug? :) Otherwise one can again loose some
data...
Ruda

[-- Attachment #2: Type: text/html, Size: 437 bytes --]

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

[ron minnich]

Ruda, go ahead and have a go at putting your key sequence into rio.
You may find it pretty easy to do ...

ron

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

2008/10/10 ron minnich <rminnich@gmail.com>

> Ruda, go ahead and have a go at putting your key sequence into rio.
> You may find it pretty easy to do ...
>
> ron
>

Well, I will try to do so, just for fun :) And if I find how :) To this end
(being a complete newbie to plan9, actually a physicist), is that ^t^tr
handled by rio?

Ruda

[-- Attachment #2: Type: text/html, Size: 679 bytes --]

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

[andrey mirtchovski]

i'm sure jmk will kill me for this. is the proc arena contiguous? if
not this could be a double-FAIL :)

% diff /tmp/devcons.c devcons.c
481,490d480
< 		case '☺':
< 			{
< 				Proc *p; int i;
< 				for(i = 0; i < conf.nproc; i++) {
< 					p = proctab(i);
< 					if(p->state == Broken)
< 						unbreak(p);
< 				}
< 			}
< 			return;

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

> % diff /tmp/devcons.c devcons.c
> 481,490d480
> <               case '☺':
> <                       {
> <                               Proc *p; int i;
> <                               for(i = 0; i < conf.nproc; i++) {
> <                                       p = proctab(i);
> <                                       if(p->state == Broken)
> <                                               unbreak(p);
> <                               }
> <                       }
> <                       return;
>

Was looking right at the same place. :) Only didn't know what to write
there...
Ruda

[-- Attachment #2: Type: text/html, Size: 1604 bytes --]

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

[andrey mirtchovski]

> Was looking right at the same place. :) Only didn't know what to write
> there...
> Ruda

notice that i've provided you with the gun but only you can pull the
trigger. i absolve myself of any responsibility :p

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

notice that i've provided you with the gun but only you can pull the
> trigger. i absolve myself of any responsibility :p
>

Unfortunately, I can't do it now either. :(
I should have already been elsewhere for a while.
But if not someone else, I will get back to it on Monday.
Thanks
Ruda

[-- Attachment #2: Type: text/html, Size: 527 bytes --]

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

[andrey mirtchovski]

On Fri, Oct 10, 2008 at 9:33 AM, ron minnich <rminnich@gmail.com> wrote:
> Ruda, go ahead and have a go at putting your key sequence into rio.
> You may find it pretty easy to do ...

if rio is broken it may not be able to figure out the key sequence. it
should go in devcons, where the rest of the ^T^T stuff is. i still
think that a hard look at ^T^TD with a lot of poking around
(preferably with a large hammer) may provide a method for killing a
particular process but i don't have a terminal handy to verify.

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

[matt]

> i'm not sure why you can't have a dedicated fileserver.
> i put mine original fs together for $12.95.  this fs is still
> running, i just wanted to put together a diskless fs.
>

Electricity is 15p per KwHour round here

300w

echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc

410.625 pounds per year

60w

82.125 pounds per year

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

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

2008/10/10 matt <mattmobile@proweb.co.uk>

>
>  i'm not sure why you can't have a dedicated fileserver.
>> i put mine original fs together for $12.95.  this fs is still
>> running, i just wanted to put together a diskless fs.
>>
>>
>
> Electricity is 15p per KwHour round here
>
> 300w
>
> echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc
>
> 410.625 pounds per year
>
> 60w
>
> 82.125 pounds per year
>

for me it is less, but I think the argument counts :)
Ruda

[-- Attachment #2: Type: text/html, Size: 999 bytes --]

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

[erik quanstrom]

> Electricity is 15p per KwHour round here
>
> 300w
>
> echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc
>
> 410.625 pounds per year
>
> 60w
>
> 82.125 pounds per year

you have a good point, though i assume you mean

	; hoc
	0.15*0.300 * 24 * 365
	394.2
	0.15*0.060 * 24 * 365
	78.84

300 watts is a hungry computer.  all 6 of my machines
here, including an 8-disk hot swappable monster, take
~550VA according to my apc.  but then again, i have
nothing but 80+-rated power supplies and a few 35w
and 65w cpus.

if power is that big a deal, it might make sense to
buy specialized hardware.  soekris come in at <20w.
an old laptop can make a good low-power fs.
portwell has a <20w atom-based mb with gbe.
you could have a small fleet of those for 60 watts.
turn off a couple of lightbulbs and tell yourself it's
free. :-)

my personal bias is toward speed and reilability.

how much is it worth to you not to worry about your
fs?  for me it's worth a lot.  even at $350/year, that's
cheep data insurance to me.

- erik

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

[Rudolf Sykora]

2008/10/8 andrey mirtchovski <mirtchovski@gmail.com>:
> while looking around for information on the RC strangeness i triggered
> a bug with rio: if the last window on the "hidden" stack disappears
> _while_ the third mouse button menu is opened, then upon attempting to
> unhide the window without releasing the mouse button in between will
> result in a read addr fault in 'wunhide()'
>
> here's a stack trace and error message:
>
> acid: lstk()
> wunhide(h=0x1)+0x30 /sys/src/cmd/rio/rio.c:1099
>        w=0x1768e0
>        i=0x0
> unhide(h=0x6)+0x27 /sys/src/cmd/rio/rio.c:1129
> button3menu()+0x97 /sys/src/cmd/rio/rio.c:686
> mousethread()+0x2c4 /sys/src/cmd/rio/rio.c:589
>        sending=0x0
>        scrolling=0x0
>        moving=0x0
>        winput=0xdaf40
>        xy=0x1f6
>        inside=0x1
>        tmp=0x0
>        w=0xdaf40
>        oin=0x929e0
>        band=0x1
>        r=0xfefefefe
>
> to reproduce:
>
> open a rio window
> run "window -hide 'sleep 10'"
> click the third mouse button (to bring the "New" menu)
> wait 10 seconds (you will know that 10 seconds have passed if you move
> the mouse over the last hidden window and the highlighted text appears
> to be gibberish)
> unhide the last hidden window by releasing the third mouse button
> while pointing at it in the menu
>
> if you simply release the third mouse button and bring the menu up
> again you will see that the window has disappeared. it is only a bug
> when rio isn't given a chance to refresh the third button menu.
>
> cheers: andrey
>
>

Although I have somehow realized that plan9 probably can't be of much
use to me, I decided to at least somehow contribute to it (before I
abandon it?) and tried to investigate what could be done with respect
to the bug described above.

Well, I am not a programmer...

In order to at least not allow rio to break completely in the
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 hidden[i] and unhide(i) can possibly pertain to completely
different windows if we somehow manage to terminate some and create
others in the meanwhile (I suppose this can happen, the code can be
interrupted and there are not locks).

[In the described example, what really happens is this. We create the
hidden window
that will exit in 10 s. Before it does, we press the 3rd button and
(keeping it down) we see the window item in the menu. By this time we
are in menuhit() function of libdraw. To this function pointers to
hidden windows' labels are passed (via Menu). When this function is
entered, it draws the physical menu on the screen with correct names.
When our hidden window exits, the menuhit() doesn't know anything
about it. Since it has drawn the physical menu on the function
entrance, when the label pointers still pointed somewhere, the screen
picture stays intact. When we move our mouse above the item which
corresponded to the hidden window, the drawing function needs to
redraw the field (to change the colours). At this moment it reads the
(now non-valid) pointer again and draws rubbish. As soon as we move
back to another item of the menu (still keeping the 3rd button down),
the drawing function redraws the field with something (a picture) it
used (and remembers) from the time the drawing function was first
entered. That's why the field looks incorrect only when being above
the field... If we release the button above the field of the now
nonexistent window, the unhide() (or wunhide()) function in rio.c
tries to unhide the window, and it gets essentially stuck. This is
where I try to intervene with my if condition.]

[In order to not see any rubbish, but a (stale; can't be much
better---the menu is rather detached from rio) menu, I thought it
would suffice to make a copy of the labels before calling menuhit()
from button3menu() in rio.c. Something like changing, close to the
beginning of button3menu(),
menu3str[i+Hidden] = hidden[i] -> label
to
menu3str[i+Hidden] = strdup(hidden[i] -> label)
and releasing the memory upon exit from button3menu().
However, then I realized, that the windows can change at any time, as
I tried to explain above, so that any such attempt is generally wrong
from the very beginning, and things have to be repaired more
thoroughly].

In this view I feel the whole thing is just flawed. I appologise to
the authors, if I am wrong. 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.
I consider it a good & only right way how it should be done today.

If someone could check it... :)
Best regards
Ruda

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

[erik quanstrom]

> 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

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

[Rudolf Sykora]

> 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

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

[erik quanstrom]

> 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