From owner-oi-users Mon Feb 20 10:26:07 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA29909 for oi-users-outgoing; Mon, 20 Feb 1995 10:26:07 -0800 Received: from marvin.boulder.openware.com (marvin.boulder.openware.com [192.245.99.138]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA29903 for ; Mon, 20 Feb 1995 10:26:03 -0800 Received: from boulder.openware.com (localhost.boulder.parcplace.com [127.0.0.1]) by marvin.boulder.openware.com (8.6.9/8.6.9) with ESMTP id LAA22080; Mon, 20 Feb 1995 11:21:49 -0700 Message-Id: <199502201821.LAA22080@marvin.boulder.openware.com> To: Peter Williams Subject: Re: Creating Application Windows in an OI_add_timeout callback Cc: OI-USERS@freefall.cdrom.com In-reply-to: Your message of Mon, 20 Feb 1995 14:32:03 +0700 Date: Mon, 20 Feb 1995 11:21:46 MST From: Warner Losh Sender: oi-users-owner@FreeBSD.org Precedence: bulk : On a Sparc Station IPX this is pretty much what happens, but as more and more : windows are created, the rate at which windows are created increases, ie the : timeout is being ignored. : : Things get pretty manic on a Sparc Station 20, my screen is rapidly filled : with windows as though the callback is being called with no timeout whatsoever. : : If rather than creating a new window in the callback, I add a new static text : item, everything works as expected. This is shown in the second test case. I think that you have found a bug that another user on OI-users ran into. The simple workaround is to delete and add the callback inside timeoutCB. The set_associated_object winds up waiting for the window to become visible, which invilvles calling OI's main loop. The timeout callbacks aren't protected for this case, due to an oversite on my part, so the timeout fires right away. The problem is more pronounced on wall timeouts, but has the potential for affecting idle timeouts as well. Warner