code:

---

$dirs=dirplus("\\@wksta\users$$", "*.*", 1, 0)
for each $sFilename in $dirs
;	$sFilename=$oDirFile.ReadLine()	; read filename from list
	$oFile=$oFS.GetFile($sFilename)	; get time/date of this file
	if not @error
		$sDate=split($oFile.DateLastAccessed(), " ")[0]	; capture the date part of this time/date info
		$saDate=split($sDate, "/")	; split the date into it's parts for checker
		if DateMath(@date, $saDate[2]+"/"+$saDate[1]+"/"+$saDate[0])>$iCheckAge	; check date against today
			$sUser=split($sFilename, "\")[4]				; capture the user name from the path
			$sFilename="H:\"+right($sFilename, len($sFilename)-len($sUser)-17)	; capture the filename
			$sDate "," $sUser "," $sFilename ?	; display to screen > csv file
		endif
	endif
next

---

Here is the DIRPLUS UDF

The UDF averages 50% cpu then when the For Each kicks in, bang 100% flat line. I could put a sleep 1 in there, sure, but when are looking at 115000 array elements, that would make this 2 hour script take an extra 32 hours!

I would be happy to make it take 4 hours if it would keep to 50% CPU.

Any ideas?

cj

one could if one could delay his loops for just an msec (enough to keep to keep nowadays CPUs stress-free, on the other side short enough to be acceptable)

Forget about udf delays as they are a CPU time killer , BUT :

Ruud promised to enable the good old SLEEP command to accept miliseconds ...

here is an excerpt from one of his last mails (hope you don't mind Ruud ?)

quote:

---

As for delay(): this is on the list for the next update after 4.02 (if all goes well, Sleep should be able to accept a floating point number, allowing you guys to sleep (your scripts ;-) for as little as a millisecond... ;-)

---

J.

_________________________

WOW .. that would result in a delay of about 2 minutes

J.

_________________________

running 2 or 3 scripts simultaneously but having other applications in foreground (Yes lads and lassies, this is sometimes inevitable if one uses KiX for administrative purposes !) shouldn't by default eat up CPU in loops !!!

But hey, the step from having SLEEP accepting floating point numbers to real floating point math support (double precision ? ) isn't that big , eh Ruud ??

J.

_________________________

However, sometimes you do want to (politely) give up CPU cycles because you don't need them. There are two reasons for this:
1) You are waiting on an event
I've got a set of UDF's for enhanced keyboard input. There is a loop which waits for a keypress, and as there is no way of giving up CPU cycles this incredibly tight little loop uses huge amounts of CPU it doesn't need. This is bad enough on a single user machine, but can be fatal on a multi-user platform like Windows Terminal Server.
2) Process scheduling
I don't know about MS Windows so much, but operating systems like Unix have a scheduler to deal with running process. The timeslice given to a running process varies depending on how busy the process has been in the past. The scheduler (not unreasonably) will give CPU hungry processes a larger processor timeslice, to the detriment of other processes, i.e. their share of the resources will degrade.

For this reason it used to be common for programmers to give up their timeslice (quorum? - can't remember) in batch type programs to ensure that the program would not hog the CPU.

One way to guarantee sleeping in milliseconds is to have your friends staying over with their new baby...

cj

I think Shawn did when I was making that tetris kix script....

just a thought.
Bryce

cj

as, in bgi.ticks()

but don't know if this is what he really ment...
but as I see it, this could be easily included in kix-dll's

cheers,

$kixlib.sleep("1") or
$Kixbgi.delay(1)

within one of the next releases of KiXtart I assume it to be :

SLEEP 0.001

J.

_________________________

got an application exception on win98-box, but this func is there according to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/prothred_7j xs.asp
maybe I just don't know how to use this feature...

as, "rundll32.exe user.exe,ExitWindows" is a api call, isn't it?

cj

All it means is that higher priority tasks will get either a larger timeslice of CPU activity, or (more properly) get more frequent timeslices. For example this might mean that for each time a low priority job gets queued to run on your CPU a medium priority job will get run twice, and a high priority job three times.

Your CPU should *never* be idle if there is work to be done. I'll stop now, I'm beginning to sound like my mother

It is a pseudo API call. Meaning that you are attempting to call a function within a dll from the rundll program.

This link will explain why you can't call it from a command line.

The Win32 Rundll and Rundll32 Interface

Note the line that says:
you can not use these utility programs to call the Win32 API (Application Programming Interface) calls exported from the system DLLs

However, this should be VERY easy to implement within the KIX executable from everything I see on the net.

Hope this helps

[ 05 February 2002: Message edited by: NTDOC ]