> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of John M McIntosh
> Sent: Monday, February 11, 2002 10:01 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Squeak is doing a *lot* of gettimeofday()
> 
> >gettimeofday({1013465648, 162274}, NULL) = 0
> >(repeated until I stop the process).
> >I'm able to work with squeak, but on my Internet server, it eats a
> >lot of CPU-time, and I think this comes from these calls.
> >
> >Thank you,
> >		Markus Fritsche
> >
> 
> If you look at the source code sqXWindow.c you'll see some logic
around
> USE_ITIMER which uses   sigaction(SIGALRM, &sa, 0); and
> setitimer(ITIMER_REAL, &iv, 0); to trigger a sig alarm every 20 msecs
> to update a low resolution ms clock. That clock as you can see gets
> called a lot. Upwards of 40,000 times a second on a fast machine.
> 
> But turning ITIMER on means  all system calls must check for EINTR,
> which I  don't think they do so there are side effects.
> 
> Under os-x (a bsd unix) I tried it and had problems with sound
> recording. So I've reverted to logic which uses pthread logic to do a
> periodic run every N milliseconds to fetch the clock value into a ms
> timer.
> 
> 
> Sooooo I'm wondering if any of the unix folks that have PTHREAD
> support should/could/would look into that type of logic. The timer
> mostly needs to be somewhat accurate, kinda. But it gets looked at a
> *lot*.
> 
> Although some u***x don't support this feature, one should take
> advantage of it if it's there to improve performance.
> 

Hi John,

This is actually a generally important discussion thread for Smalltalk
vm's. I.e., timer tasks, and periodic interrupts.

As you may know, the timer services on windows are relatively expensive
and for Win95/98/ME they suck up limited resources. Which means you
don't want to use them. There are some different issues for MacOS9X and
earlier.

The general model I use on the AOS VM, is very much like (maybe the same
as?) your pthread approach. Eliot Miranda and I talked about how to
implement efficient cross-platform timers based on threads some four
years ago, and I believe he adopted my AOS VM technique for VW Win32.
I'm pretty sure that Blair (Dolphin) talked to Eliot a year or two later
and that Dolphin now also uses the technique.

The basic idea is that if the native system provides pre-emptive
threads, then it is also scheduling them on a timer with pretty fine
grained units. [We could go into precise discussions of quantums on
various OS'es but the details are not important].

The important point is that one can create hi-priority threads that will
run pre-emptively at regular intervals. On many systems the cost to run
such threads is nominal if one is clever.

The clever part is to take advantage of the native systems
sleep/event/interrupt mechanism.

a) Create a native thread, we'll call the "scheduler".

b) The scheduler is a high-priority [non-Smalltalk] watchdog thread that
sleeps most of its life waiting for either its sleep period to expire,
or a semaphore/interrupt to be signaled. This thread can do lots of
other usefully tasks as well, but in this discussion we'll stick to the
timer task issues.

c) The VM maintains a temporally sorted global queue of timer tasks.

d) Whenever a new task is added to the queue it is inserted in temporal
order.

e) If the new task is at the head of the queue then the scheduler is
woken up (via signaling the scheduler semaphore) with a flag-value [of
some form] that tells it when it set a VM/Smalltalk [soft] interrupt (a
timer task interrupt). The flag-value typically indicates when [in OS
tick-timer milliseconds] the scheduler it should set the VM's [soft]
interrupt bit. So when the scheduler wakes up, it looks at the request,
reads the OS tick-timer and compares the two and then sleeps on the
difference. If, upon comparing them, the time has expired, it sets the
VM's [soft] interrupt bit and clears the flag-value.

f) Whenever the global VM's [soft] timer task interrupt is handled, it
examines the timer-task objects and values each one that has expired. It
then looks at the head of the queue and performs the same sequence as in
step (e) to wake up the scheduler.

There are numerous variations on this theme, and my description above
glosses over actual implementation details/decisions. The choice of
implementation approach largely depends on whether your VM uses
green-threads (classic Smalltalk Processes), or pre-emptive native
threads.
---

With this type of scheme, very few cycles are consumed because it is
fundamentally an interrupt model rather than a polling model. Code
relating to temporal task management/scheduling/dispatching is only
executed when a timer task expires. No time is spent polling for tasks.
So if you're Smalltalk code has little or nothing happening (in a
temporal sense) then it uses no cycles. Idle tasks can be scheduled as a
periodic (synchronous) timer task. [Synchronous means it is posted on an
event queue for serialized processing, whereas asynchronous means it is
executed/evaluated at VM [soft] interrupt processing time].

Using this basic VM level service, it then becomes easy to build a
portable higher per/process timer task system. Where timer tasks can be
one-shot, periodic, synchronous, asynchronous, etc.

Skipping a number of implementation specific details and variations,
this is the basic facility that is now used within the SmallScript (AOS)
VM, and other Smalltalk VM's like VW and Dolphin.

This mechanism is implementable across almost every major OS. A slight
variation using a single high-precision timer is the preferred approach
on systems like MacOS9X and earlier.

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org

> --
> --
>
========================================================================
==
> =
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.
http://www.smalltalkconsulting.com
>
========================================================================
==
> =