[cmucl-help] Re: Threads
* Greg Bennett <4978cba5.5080...@sentex.ca> : Wrote on Thu, 22 Jan 2009 14:40:21 -0500: | All this exists in Quail now. However the graphics used by | mcl/digitool and allegro_cl do not take charge of the main repl. So we | are able to (1) run some analyses, (2) note some interesting feature, | (3) use dialogs and menu options to explore further where those | explorations are 'registered', (4) but if they are not, we can send | instructions from the repl to the views to show some additional stuff, | on the fly, in typical lisp interactions, without disturbing any of | the available graphics processing. | | It is this last form of interaction which, as far as I can see, would | not be possible using OpenGL. The problem is that even if you used threads as indicated in the parallel reply the thread may not get a chance to run. Against my better judgement -- Here is the comment from (multi-processing.lisp), so you see the BIG FAT warning first /--- ;;; Start-Sigalrm-Yield -- Internal ;;; ;;; Start a regular interrupt to switch processes. This may not be a ;;; good idea yet as the CMUCL code is not too interrupt safe. (defun start-sigalrm-yield (&optional (sec 0) (usec 50)) "Start a regular SIGALRM interrupt which calls process-yield. An optional time in seconds and micro seconds may be provided. Note that CMUCL code base is not too interrupt safe so this may cause problems." ... ) \ Now in the CMUCL REPL top level if you called * (MULTIPROCESSING::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS) * (mp::start-sigalrm-yield) * (mp::make-process (lambda () (cl-glut-examples:glut-teapot))) You ought to able to interact with the process. BUT THIS CAN NOT BE EXPECTED TO BE RELIABLE and can break. There are also some other knobs one can tweak ... [This is in a vanilla lisp without slime. In the context of slime swank communication style, I believe this corresponds to the SWANK:*COMMUNICATION-STYLE* :sigio . --- Maybe this will work for you immediately, I don't know. But in general, BEWARE. SLIME may make other assumptions about the "multi-threading" model, and should be isolated when debugging failures. I haven't looked much at cl-opengl --- I did use kt-opengl (from Ken Tilton's Cello project) briefly with CMUCL, but mostly only in a single-threaded model of development, and I haven't gotten around to fixing the problems to be happy about it] | Let me display my ignorance of one piece of shorthand, what is an 'fd' | as in REPL fd ? The UNIX file descriptor of the stream. * *terminal-io* # * system:*tty* # * (type-of *) SYSTEM:FD-STREAM * (system:fd-stream-fd system:*tty*) 4 * (system:fd-stream-fd system:*stdin*) 0 * (system:fd-stream-fd system:*stdout*) 1 * (system:fd-stream-fd system:*stderr*) 2 * -- Madhu
[cmucl-help] Re: Threads
Greg Bennett wrote: > Many thanks to Martin Cracauer and Madhu for their replies to my > original query. > Madhu puts his finger neatly on the crucial point in his comment > (below) on OpenGL. > > In thinking about porting a large statistical project > (www.stats.uwaterloo.ca/Quail) to Linux, > it seemed useful to consider rewriting its graphics component to use > OpenGL which many speak > about very positively as a graphics standard. Not directly applicable, but there is clasp (common lisp analytical statistical package) and clip (common lisp instrumentation package). It uses CLIM for it's GUI, and I played with the code sometime back. With some small tweaks, it runs fine with McCLIM. No fancy GL stuff, but it does draw 2D graphs, and can do some interesting statistics with a lisp repl to run everything. Ray
[cmucl-help] Re: Threads
Many thanks to Martin Cracauer and Madhu for their replies to my original query. Madhu puts his finger neatly on the crucial point in his comment (below) on OpenGL. In thinking about porting a large statistical project (www.stats.uwaterloo.ca/Quail) to Linux, it seemed useful to consider rewriting its graphics component to use OpenGL which many speak about very positively as a graphics standard. Apologies if I have a wrong view on things in what follows. I have a copy of the Redbook, which early on emphasises the description in Madhu's note below: once OpenGL's main loop is fired up, all the graphics stuff is, as it were, off limits. Thus, if I have it aright, the idea of 'interactive' which OpenGL supports is encapsulated in the registered callbacks established at the time the call to the main loop is made. These callbacks take the form of, eg. mouse events, including results from menus, keyboard events, including results from dialogs. All this exists in Quail now. However the graphics used by mcl/digitool and allegro_cl do not take charge of the main repl. So we are able to (1) run some analyses, (2) note some interesting feature, (3) use dialogs and menu options to explore further where those explorations are 'registered', (4) but if they are not, we can send instructions from the repl to the views to show some additional stuff, on the fly, in typical lisp interactions, without disturbing any of the available graphics processing. It is this last form of interaction which, as far as I can see, would not be possible using OpenGL. Thank you again for you patience in helping me understand things a little better. Let me display my ignorance of one piece of shorthand, what is an 'fd' as in REPL fd ? Cheers /Greg Bennett Madhu wrote: * Martin Cracauer <20090121162515.ga20...@cons.org> : Wrote on Wed, 21 Jan 2009 11:25:15 -0500: | You definitely want to do an event loop on the REPL fd and the | graphics subsystem here, no threads. | | Whether it's easy to hack up cl-opengl to do that is a different | matter but it would be wise on their part to provide a hook for an | event loop. | | The threads in CMUCL won't work reliably as-is, green or not. You're right of course, and my suggestion to use CMUCL:MP will not work as expected. I apologise for posting that. An example of how to do the event loop is in ltk.lisp (look for SERVE-EVENT and comments there). However this LTK approach has not worked reliably for me. Only CLX has been satisfactory. The problem with ALL foreign GUIs (GLUT, TCL, etc) is that they want control of the main loop and it is is entirely in foreign land. The application makes a foreign call to (say for example) glutMainLoop(3GLUT) , | enters the GLUT event processing loop. This routine should be called at | most once in a GLUT program. Once called, this routine will never | return. It will call as necessary any callbacks that have been | registered. ` Once you hand over control to the foreign code, youre done. [If somewhere the foreign code decides to call exit(2) your lisp process dies]. Registering a callback to process events on other FDs may not be always be feasible or reliable. -- Madhu
[cmucl-help] Re: Threads
* Martin Cracauer <20090121162515.ga20...@cons.org> : Wrote on Wed, 21 Jan 2009 11:25:15 -0500: | You definitely want to do an event loop on the REPL fd and the | graphics subsystem here, no threads. | | Whether it's easy to hack up cl-opengl to do that is a different | matter but it would be wise on their part to provide a hook for an | event loop. | | The threads in CMUCL won't work reliably as-is, green or not. You're right of course, and my suggestion to use CMUCL:MP will not work as expected. I apologise for posting that. An example of how to do the event loop is in ltk.lisp (look for SERVE-EVENT and comments there). However this LTK approach has not worked reliably for me. Only CLX has been satisfactory. The problem with ALL foreign GUIs (GLUT, TCL, etc) is that they want control of the main loop and it is is entirely in foreign land. The application makes a foreign call to (say for example) glutMainLoop(3GLUT) , | enters the GLUT event processing loop. This routine should be called at | most once in a GLUT program. Once called, this routine will never | return. It will call as necessary any callbacks that have been | registered. ` Once you hand over control to the foreign code, youre done. [If somewhere the foreign code decides to call exit(2) your lisp process dies]. Registering a callback to process events on other FDs may not be always be feasible or reliable. -- Madhu
[cmucl-help] Re: Threads
Greg Bennett wrote on Tue, Jan 20, 2009 at 08:23:36PM -0500: > 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. You definitely want to do an event loop on the REPL fd and the graphics subsystem here, no threads. Whether it's easy to hack up cl-opengl to do that is a different matter but it would be wise on their part to provide a hook for an event loop. The threads in CMUCL won't work reliably as-is, green or not. Martin -- %%% Martin Cracauerhttp://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
[cmucl-help] Re: Threads
* Andreas Davour : 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) 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
[cmucl-help] Re: Threads
* Andreas Davour : 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) 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
