Date: Mon, 22 Mar 1999 20:04:33 GMT
Message-Id: <199903222004.UAA06832@toy.william.bogus>
From: William Chesters <williamc@dai.ed.ac.uk>
To: caml-list@inria.fr
Subject: Re: threads & OCamlTK
In-Reply-To: <199903221839.NAA20107@saul.cis.upenn.edu>
<199903221839.NAA20107@saul.cis.upenn.edu>
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
completely!).
> 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.)
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:21 MET