CLIM mail archive
[Prev][Next][Index][Thread]

A Kinder Gentler Event Loop

    Date: Thu, 14 Mar 1991 19:32 EST
    From: Mike Shaff <shaff@rpal.rockwell.com>

    I am attempting to construct a somewhat robust version of an extension to CLIM.
    The extension I wish to build will supply two things:

      - Periodic events (otherwise known as timer events)
      - Idle events

    This is in an ideal world, I recognize I am dealing with Common Lisp, CLOS, and
    CLIM and will therefore probably settle for something much less.

Common Lisp, CLOS, and CLIM have very little to do with what you want.
Periodic timers are a service that either are, or are not, provided by
the scheduler of whatever operating system you are using.  Common Lisp,
CLOS, and CLIM enter into the equation only when you wish to have them
interface to the operating system.

Your only other choice is to have the event loop run continuously,
waiting for a period of time to elapse by watching the clock, since
SLEEP provides granularity of one second.

    Regarding periodic events the minimum functionality I need is to generate a
    timer event every clim-bogus-extensions:*timer-event-interval*.  Idle events in
    this minimum functionality system would be generated after
    clim-bogus-extensions:*microseconds-till-idle* or some such nonsense.  These
    variables are made global in the hope of having the settings apply to a given
    application frame process, rather than every application frame (using the
    special variable handling of processes in the somewhat common process
    interface).

    I am trying to do this in such as way as to avoid rewriting in a serious way
    the extensions after each CLIM release.  This seems reasonable, right?

Frankly, no.  The implementation of the event loop varies from platform
to platform, and is an internal part of the CLIM implementation.  You
cannot depend on it not changing.

    The entire event methodology seems to evade any firm grasp by my humble
    understanding.  One could even say that the more I work with CLIM code the less
    I understand, but that is another story.  Simplistically, There is a layer of
    event metaphor in CLIM built upon a silica layer that supplies the underlying
    mechanics and event definition.  I initially based my implementation on the
    Silica layer with mixed results.  This seemed logical as it had such macros as
    sio2::define-event-type, which though an internal appeared to be a valid
    starting point.

    Now, for a while now I have been listening to talk about CLIM version x being
    based on the Symbolics' version and version x+y being the unification of ILA's
    version and Symbolics version.  Suddenly this week I was struck with the
    realization that a Symbolics version implied the absence of a Silica layer.  My
    already floundering spirits sank deeper into the murk.

The event model in CLIM Release 1.0 is simpler (or more simple-minded,
if you prefer) than the one provided by Silica.  If anything, it is
easier to understand because it does less.  But, as you have deduced,
the event layer will almost certainly change radically between CLIM
Release 1 and CLIM Release 2.

    After spending a few days looking more intensively at the CLIM layer, I am
    completely baffled as to how it would be possible to implement my fondest
    desires using only this layer.  Yet, it seems this is the only layer available
    until some unknown time in a calmer future.  I turn, therefore, to this great
    band of information with my plight.

    Can you help us Obi-Wan Kenobi?

This OWK is unable to provide you any good advice.  It is much too late
in the CLIM Release 1 development cycle to implement timers in the event
loop.  Perhaps the people designing Release 2 can be persuaded.  You can
help by being extremely specific about what it is you need.

0,,
Follow-Ups: References:
Main Index | Thread Index