From: Stas Sergeev <stsp@aknet.ru>
To: linux mailing list <linux-msdos@vger.kernel.org>
Subject: Re: Dosemu and clipper applications eating all CPU
Date: Mon, 15 Mar 2004 22:17:10 +0300 [thread overview]
Message-ID: <40560136.6090308@aknet.ru> (raw)
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.
next reply other threads:[~2004-03-15 19:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-15 19:17 Stas Sergeev [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-28 17:32 Dosemu and clipper applications eating all CPU Stas Sergeev
2004-04-28 5:55 Mgr. Peter Tuharsky
2004-04-28 19:52 ` Maximiliano Curia
2004-03-15 17:50 Stas Sergeev
2004-03-15 18:07 ` Maurilio Longo
2004-03-12 22:33 Stas Sergeev
2004-03-15 11:53 ` Maurilio Longo
2004-03-11 18:44 Stas Sergeev
2004-03-10 19:36 Stas Sergeev
2004-03-10 22:55 ` Maurilio Longo
2004-03-11 8:29 ` Maurilio Longo
2004-03-10 18:36 Stas Sergeev
2004-03-09 20:16 Stas Sergeev
2004-03-10 15:29 ` Peter B. Steiger
2004-03-10 19:11 ` Maximiliano Curia
2004-03-08 16:11 Maximiliano Curia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40560136.6090308@aknet.ru \
--to=stsp@aknet.ru \
--cc=linux-msdos@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.