From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: Dosemu and clipper applications eating all CPU Date: Mon, 15 Mar 2004 22:17:10 +0300 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <40560136.6090308@aknet.ru> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux mailing list Hello. Maurilio Longo wrote: >> in 1.3.1. Does your prog work in real >> or protected mode for you? > it is in protect mode, I don't know if it could run at all in real > mode. Perhaps not. This may sound strange, but I have one prog here which uses Blinker but can work in both real and prot mode. The program can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=913663&group_id=49784&atid=457448 I also have another Blinker-based prog which can't work in real mode, and therefore can't work in any dosemu prior to 1.3.1. But your Blinker-based program works in prot. mode even in 1.1.3 - what version of Blinker extender does it use? Mine uses 3.30, which was never supported under dosemu until recently (MaxThink and stuff). > Yes, it _does_ and this makes our clipper program unresponsive to user > commands But the original problem was that dosemu eats 100% of CPU. It seems you have a strictly opposite problem. But I find that strange also. The code in int.c I was referring to, when $_hogthreshold=(2), will call usleep() every 100th call of int21/ah=1c and crawles the dosemu for you. But then you modify the code to make it call usleep() every 50th path (with a different delay of INT28), and it works better, even though it should call usleep() twice as more frequent than with $_hogthreshold=(2). Perhaps there is another location in dosemu where usleep() is called too frequently (and makes your app irresponsive). Do you have any idea where is it? > But the problem, in my opinion is that usleep() sleeps a fixed amount of time > (either INT2F_IDLE_SEC or INT28_IDLE_SEC) while it should simply (if at all > possible on linux) give back the rest of current time slice May be, maybe not. I don't think it is a problem. If we call usleep() every 50th invocation of int21/ah=1c, and that invocations are happening once per, say, 10 timeslices, the difference might not be noticeable. INT2F_IDLE_USECS is defined as 80ms, which is 8 Linux timeslices.