Skip to contentSkip to conversation

Dosemu and clipper applications eating all CPU

DISCUSSION Stas Sergeev 1 participant 1 message Mar 15, 2004

lore
Share & tools
lore
#0 lore raw

Hello.

Quoted 4 lines · Maurilio Longo
Quoted 2 lines

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).

Quoted 2 lines

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?

Quoted 3 lines

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.