From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AE44DBC75 for ; Wed, 2 Mar 2005 09:48:08 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j228m8pI013596 for ; Wed, 2 Mar 2005 09:48:08 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA05444 for ; Wed, 2 Mar 2005 09:48:07 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j228m56G031932 for ; Wed, 2 Mar 2005 09:48:07 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j228m3fT012155; Wed, 2 Mar 2005 17:48:03 +0900 (JST) Date: Wed, 02 Mar 2005 17:48:03 +0900 (JST) Message-Id: <20050302.174803.68555775.garrigue@kurims.kyoto-u.ac.jp> To: jon@jdh30.plus.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] lablGL and the top-level From: Jacques GARRIGUE In-Reply-To: <200503020818.16207.jon@jdh30.plus.com> References: <200503020818.16207.jon@jdh30.plus.com> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42257DC8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42257DC5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 lablgl:01 ocaml:01 lablglut:01 mainloop:01 ocaml:01 threads:01 lablgtk:01 -thread:01 toplevel:01 lablgtk:01 toplevel:01 gtkthread:01 callbacks:01 unix:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: From: Jon Harrop > It just occurred to me that the ability to run an interactive top-level to > write and test OpenGL programs would be quite alluring. In particular, this > would be a great way to introduce students to ocaml and graphics. > > However, I'd like to use lablglut, which requires execution to be handed over > to glut via a final call to glut.mainLoop. So, what would be the best way to > get glut and the ocaml top-level to interoperate? > > I guess you could write a glut idle function which provokes the top-level into > asking for more input, but the display wouldn't be updated in the mean time. > > Any ideas? Threads are the natural way to do this. This is already possible with GlGtk, using lablgtk -thread. If you want to do this with glut, I see two possible approaches: * Run the glut main loop in a different thread, and have it exit every 100ms so you can yield and run the toplevel thread during this time (this is basically the way this is done in lablgtk) This is safe, but supposes there is an easy way to exit and reenter the main loop frequently. * Release the ocaml mutex with caml_enter_blocking_section when entering the main loop. This of course means you must call caml_leave_blocking_section before calling any callback. Fortunately there are not too many ways to enter callbacks in glut. However, there is a further difficulty: you must avoid race conditions when making calls to openGL from the toplevel. The simplest way to do that is not doing calls directly, but putting them in a queue, and executing them in an idle callback from glut. Such an infrastructure is defined in gtkThread.ml (for windows users) The first way is simpler on Unix (no races for free), but the Windows GDI is such that you cannot call graphical functions from another thread anyway, so you end up needing the queue. The second approach feels cleaner, but is harder to program in. Jacques Garrigue