Hello.
Maurilio Longo wrote:
it is in protect mode, I don't know if it could run at all in real mode.in 1.3.1. Does your prog work in real or protected mode for you?
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. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
