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

How to manually poll for events

    Date: Wed, 24 Jun 1992 18:12 EDT
    From: Greg Siegle <siegle@aristotle.ils.nwu.edu>

       I'd like to be able to click on a presentation which calls a
    function which contains a potentially infinite loop, and still be able
    to click on other presentations on the screen and have them respond
    while that function is looping. It seems that as soon as I click on
    one presentation, the other presentations on the screen aren't
    clickable until the function called by my first click is finished
    executing. Do I need to make my own run-frame-top-level function (I'm
    using the default right now)?

Your question has almost nothing to do with CLIM (that is, the answer
would be almost the same in any interface), and everything to do with
multiple processes, threads, or stack-groups.  Since you don't say what
platform you have CLIM on (ahem...) I'll answer in general terms with
some reference to Genera.  (Sticking to Genera terminology, I use
"process" where Unix folks would probably say "thread".  For purposes of
this discussion they're equivalent.)

In a single process, your other presentations aren't sensitive "until
the function called by [your] first click is finished executing"
*because* the function called by your first click hasn't finished
executing.  Your process is busy doing what you told it to do - that is
- run the first function.

To get the behaviour you want, you must have either have multiple
processes, or do some event-polling from within your "potentially
infinite" function.  I regard polling as the inferior choice, since it
requires that your function have knowledge of events and the like -
which strikes me as smearing the modularity.

To implement what you want, I would have the first click run a very
short function which spawned another process to run the "potentially
infinite" function.  Process 1 returns to the command loop almost
immediately and your presentations are sensitive.  Meanwhile Process 2
is busy churning away.  The interface application keeps track of Process
2 so it can know when it finished, kill it, restart it, or whatever.

Note: it is not a good idea for Process 2 to do output directly to the
CLIM frame.  You would have to add locking to ensure that two processes
didn't mess with each other's output.  Instead, the interface should
examine the state of Process 2, or its results, as part of the top level
loop.

Alternately, facilities so that Process 2 could insert a command in the
application's input queue could be used.  This isn't provided yet, but
some recent discussion on this list suggests that it may be soon.
References:
Main Index | Thread Index