From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <02618374130ebdd5134f41b110f18a3c@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] winname: undocumented file in rio. From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 6 May 2003 19:28:14 +0100 Topicbox-Message-UUID: a007adae-eacb-11e9-9e20-41e7f4b1d025 > < .B winname > < contains the string window.n1.n2 where n1 is the number for the window > < and n2 is the number of times the window has been renamed. Typically it > < indicates the number of resizes and moves it has suffered. that reminds me: there's a bug in the way that rio uses winname which can cause applications to fall over. it's a race: if i try to resize a window several times in quick succession, rio can have destroyed a window's image before the application has actually acquired it with namedimage(). various applications, including acme, panic if this happens. the problem is not fixable "properly" without adding some sort of acknowledgment channel to rio so an application can tell rio that it has successfully acquired the new image. this seems like overkill, especially as it's hardly ever a problem. i think the best solution might just be to continue to use the old image in the meantime, as the nature of the problem means that it will resolve itself once the rest of the resize events have been delivered. (after all, there *is* an image for the window, it just isn't the one that the application currently has the name for). does this seem reasonable? the implementation should be trivial. i have been bitten by this several times; having an acme window suddenly die is most annoying! cheers, rog.