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