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