* Andreas Davour <pine.lnx.4.64.0901210424240.29...@psilocybe.update.uu.se> : Wrote on Wed, 21 Jan 2009 04:26:58 +0100 (CET):
| On Tue, 20 Jan 2009, Greg Bennett wrote: | |> Good evening all. I am trying to learn how OpenGL operates via |> cl-opengl and cmucl-19e. While I can compile the graphics demos and |> run them, I lose control of cmcl's repl. I can certainly type |> characters into it; there is no eval running as far as I can see. |> Those characters appear to be fed to eval when I kill the graphics |> loop/processes. | |> Perhaps someone of you can point me to documentation about ensuring |> the necessary division of processes so that I can plough on into |> opengl. As Andreas Davour indicated, On X86 platforms you can use the decade-old-but-still-"EXPERIMENTAL" "green-threads" multi-processing facility: If you have a function that passes control off to GL-land, you could do: * (mp:make-process (lambda () (cl-glut-examples::rb-movelight))) And the MP:PROCESS would exit and be cleaned up when the GL window closes. This works but has some rough edges. If you go this route, you could, BUT ONLY at the REPL Top level, do * (MULTIPROCESSING::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS) To start an idle loop which may speed up responsiveness. More details in probably in your CMUCL manual. [snip] | I know nothing about cl-opengl, but if you want to use threads in a | serious way you might want to take a look at the bordeaux-threads | package. Look at cliki. It's supposed to be threaded lisp programming | that's implementation independant. [While both have problems with CMUCL MP ATM I'd recommend the PORTABLE-THREADS package over BORDEAUX-THREADS as I believe it has a better API, (suits my tastes better) <URL:http://GBBopen.org/hyperdoc/ref-portable-thread-entities.html> Here, It'd look like: * (portable-threads:spawn-thread "Test" 'CL-GLUT-EXAMPLES:RB-MOVELIGHT) ] | Otherwise I'd suggest you investigate what the CMUCL manual has to say | about the MULTIPROCESSOR package, i.e. MP. -- Madhu
