From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA06991 for caml-red; Wed, 7 Feb 2001 22:38:06 +0100 (MET) 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 BAA08276 for ; Wed, 7 Feb 2001 01:42:46 +0100 (MET) Received: from localhost.localdomain (jimbo52.zip.com.au [202.7.88.52]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f170ge919700; Wed, 7 Feb 2001 01:42:42 +0100 (MET) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id LAA12881; Wed, 7 Feb 2001 11:39:25 +1100 Message-ID: <3A80993D.1E4F8295@ozemail.com.au> Date: Wed, 07 Feb 2001 11:39:25 +1100 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Xavier Leroy CC: Daniel Ortmann , caml-list@inria.fr Subject: Re: OCaml's long range graphical direction? References: <20010206102842.A27059@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr Xavier Leroy wrote: > > > Xavier, > > Please speculate on the future development direction of graphical support > > in OCaml. > > To what degree does threading affect the answer? > > No idea. I've heard plenty of claims that multithreading helps > building good GUIs (see e.g. BeOS), yet most popular GUIs (including > TK and I think GTK too) seem to manage fine without multithreading. No. Tk is not re-entrant/thread-safe and never will be. (I'm paraphrasing Ousterhout's own claim). When 'normal' functions are called, one can always use a global lock to get around this problem, but this is not the case for a GUI like Tk, which takes control of the system and invokes user code _entirely_ using callbacks. When another thread also invokes the Tk mainloop, all hell breaks loose, since state data is held in static storage. It does no good to use a lock, since the first thread never regains control, and so the second will be excluded permanently. As far as I know, GTK has been built with an eye to making it multi-threadable .. later (that is, it suffers the same problem as Tk at present). MS-Windows is miles ahead here. One 'solution' to this problem is to have a single 'GUI' server thread, and have all client threads 'post' to that server. Server callbacks can use locking to update shared locations. Unfortunately, this requires construction of a complete client-side binding of the API to create a queue of service requests, and a server side binding to pick them up from within the event dispatch loop during idle time and process them. [And event handling is event harder ... ] Note that Tcl (8.xx) is multi-threadable, since state data can be captured in interpreter objects, of which there can be many (at least one per thread ..). -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net