[Haskell-cafe] FFI and callbacks

Sebastian Sylvan sebastian.sylvan at gmail.com
Mon Aug 22 12:13:07 EDT 2005


On 8/22/05, Duncan Coutts <duncan.coutts at worcester.oxford.ac.uk> wrote:
> On Mon, 2005-08-22 at 15:45 +0200, Sebastian Sylvan wrote:
> 
> > I haven't found any issues with wxHaskell misbehaving when it's called
> > from different threads, but I'd like to know for sure that it's
> > actually honest-to-goodness thread safe. So does anyone know?
> 
> Actually here's an even more direct statement. From:
> 
> http://www.wxwidgets.org/whychoos.htm
> 
>         Multithreading
> 
>         Like many frameworks, wxWidgets isn't 'thread-safe' in the sense
>         that the programmer can use GUI code indiscriminately from
>         threads, but it does have a range of thread and mutex classes
>         for the careful and more ambitious programmer. These classes are
>         under development.
> 
> Unfortunately, when using wxHaskell (or indeed Gtk2Hs) with -threaded,
> this is exactly what's happening "using GUI code indiscriminately from
> OS threads".
> 
> Which is why we need some better solution.


Hmm... Perhaps some operations are thread safe? It would seem that
there's no real reason for why "appendText" couldn't be thread-safe
(maybe it just triggers an event for the control which is then handled
by the event-system on the C-side).
It certainly does seem that in this particular case it does work. It
would be nice to know exactly when it works, and exactly when it
won't.

I want my forkIO's dammit! Using a timer to yield every 20 ms may work
fine for an app with just one or two threads, but for each thread you
spawn you potentially add 20 ms latency to other threads which quickly
becomes unacceptable.
It's especially troublesome when the number of threads varies, cause
then you'll have to prioritize between excessive polling or too high
latency...

/S

-- 
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell-Cafe mailing list