Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
threads & OCamlTK
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: William Chesters <williamc@d...>
Subject: Re: threads & OCamlTK
Trevor Jim writes:
 > I've been using camltk with threads for a while.  I find it is faster
 > to run Tk as its own process -- the thread scheduler doesn't seem to
 > do a good job with Tk involved.

   Yes, I have found the same (Linux w/pthreads).  CPU usage varies
between 20% at best and near zero at worst, depending on what else is
going on (that's why I originally thought Tk blocked threads

 > My program uses one thread to run a Tk gui.  I have the gui
 > periodically poll for input from the other threads.

   I do a Fileevent.add_fileinput on a Unix pipe to which I write a
byte when I want to get control of the Tk thread.  Using a pipe to
communicate between threads is not exactly clean but it avoids
polling ...

   However I have now gone back to forking and passing code to execute
by marshalling over IPC, because of the performance problems.

   Incidentally I found the most flexible thing way to support this
model was to use Hashtbl in combination with Obj.magic, allowing for
the creations of "sessions" with arbitrarily typed persistent state.
(The interface is still type safe.)