Newsgroups: comp.lang.lisp.franz
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!eff!news.umbc.edu!haven.umd.edu!ames!kronos.arc.nasa.gov!usenet
From: bobo@avogadro.arc.nasa.gov (Mark Friedman)
Subject: Speeding up Multiprocessing Response
Message-ID: <BOBO.95Feb13163346@avogadro.arc.nasa.gov>
Lines: 30
Sender: usenet@ptolemy-ethernet.arc.nasa.gov (usenet@ptolemy.arc.nasa.gov)
Nntp-Posting-Host: avogadro.arc.nasa.gov
Reply-To: bobo@ptolemy.arc.nasa.gov
Organization: NASA/Ames Information Sciences
Date: Tue, 14 Feb 1995 00:33:45 GMT

I've got an application which runs an event loop (Tk, if you're
interested) in a separate process. The default priority of 0 does not
quite give me good enough interactive response. If I raise the
priority to 100 or 10 my Lisp REP loop freezes up. My guess is that
because the priority of the REP loop process is 0 it never gets any
cycles because my higher priority loop is always ready to run. My loop
looks something like this (this is a simplified form):

(defun tkloop (&optional (priority 0))
  (process-run-function ;; Start a Lisp process to handle the loop.
    `(:name ,loopname :priority ,priority)
    #'(lambda ()
        (do () (*tk-loop-exit*)  ;;Busy loop forever unless *tk-loop-exit*
	    (tk-dooneevent *tk-dont-wait*)
	    ;; This gives us fair interactive response time.
	    (process-allow-schedule))))))

Does anybody have any ideas on how to get better response for this
loop?

-Mark
-- 
--
Mark Friedman
NASA-Ames Research Center
MS 269-2
Moffett Field, CA 94035-1000

vmail: (415) 604-0573
email: bobo@ptolemy.arc.nasa.gov
