* Re: Clipper idle mode, usleep and alrm
2004-05-14 19:30 Clipper idle mode, usleep and alrm Maximiliano Curia
@ 2004-06-04 7:52 ` Miroslav Mickey Lazarevic
0 siblings, 0 replies; 3+ messages in thread
From: Miroslav Mickey Lazarevic @ 2004-06-04 7:52 UTC (permalink / raw)
To: linux-msdos
On Friday 14 May 2004 21:30, Maximiliano Curia wrote:
> Hello,
>
> I'm still working out a way to limit the cpu utilization of clipper
> programs.
>
> The problem I'm looking now is that even if the usleep parameter is high
> enough (say JIFFIE_TIME*100), the process never stops eating cpu, nor
> does completes it's sleep time.
>
> Doing an strace I see a lot of SIGALRM which, I presume, are waking it
> up all the time. Could it be?
>
> I'm sure I'm missing something.
Why you doing this when you have a Clipper library for this problem? You need
"nanfor.lib" with "cpmi.lib" and to put next line on top of your Clipper
program: ft_onidle( { || ft_iamidle(30, .t.)}). This will reduce CPU
utilization near 0% when clipper app is idle.
You can read about this from next document:
--------------------------------------------------------------------
Nanforum Toolkit v3.05 Patch #1 09/06/96
--------------------------------------------------------------------
There have been some complaints that FT_IAmIdle() failed to release
the CPU timeslice under certain conditions. The problem occurred
ONLY in protected mode applications, and ONLY under some operating
systems (Windows NT was specifically mentioned, but others may be
affected as well -- however, the problem does NOT appear to occur
under Windows 3.1x, Windows 95, or OS/2).
In addition, there have been less serious complaints that
FT_IAmIdle() did indeed release the timeslice, but was only
marginally successful in doing so (e.g. during idle states, CPU
usage dropped from 100%, but still remained high -- in some cases
60% or 70% which still had a negative effect on any other tasks
that might be running concurrently).
This patch addresses both of these problems by adding two OPTIONAL
arguments to FT_IAmIdle(). The new syntax is:
FT_IAmIdle( [ <nIntensity> ], [ <lForceReal> ] )
<nIntensity> is an optional numeric value that varies the intensity
of the timeslice release. The default is 1, and should be fine for
most operating systems. You can experiment with higher values to
determine if you get better timeslicing (limited experimentation
with Windows NT showed that values between 10 and 30 seemed to
work pretty well).
<lForceReal> is an optional logical argument. If a value of .T. is
passed, FT_IAmIdle() will force the CPU to switch to real mode
before releasing the time slice (this had a DRAMATIC effect under
Windows NT). The default is .F., which causes FT_IAmIdle() to
remain in the current CPU mode when releasing the time slice. In a
real mode application this argument is ignored.
Remember that both of these arguments are optional, and the default
values were chosen so that the function would retain its previous
behavior if the arguments aren't passed. If you are not
experiencing any problems with FT_IAmIdle(), just continue calling
it as you do currently, and you can remain blissfully unaware of
this patch.
To apply the patch, just replace IAMIDLE.ASM in your NFSRC.ZIP with
the attached IAMIDLE.ASM (if you downloaded the source code).
Then, you need a library utlitity (LIB.EXE comes with many versions
of DOS, and with most compilers, and can be downloaded from the MSL
forum on CompuServe as S12776.ARC). If you know what to do, simply
replace the IAMIDLE.OBJ module with the new one that is included in
this patch file.
The procedure, for those not sure:
1. Make a safe copy of NANFOR.LIB. Hide it away.
2. Change to the directory where NANFOR.LIB is located.
3. Put IAMIDLE.OBJ in the same directory as NANFOR.LIB.
4. Type
LIB NANFOR -+ IAMIDLE;
That should do it.
Remember to report all bugs in Section 16 of the CLIPPER forum! If
you have any problems, please contact me.
Ted Means [73067,3332]
--
Best regards,
Mickey mickey@birosoft.com, mickey72@neobee.net
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread