Axel, this is great news, many thanks for working on it!
I'm interested in using Cairo from multiple threads. What exactly is
supported there? Can I run an arbitrary Render operation on any thread
I like?
Cheers,
Simon
On 22/11/09 19:58, Axel Simon wrote:
> Dear Simon, Duncan,
>
> -threaded now works with Gtk2Hs. See below.
>
>
> On Tue, 2009-11-10 at 14:14 +0000, Simon Marlow wrote:
>> On 10/11/2009 13:52, Axel Simon wrote:
>
>>>> Does the traceback in my original message give you enough information?
>>>> (reproduced at the end of this message)
>>>
>>> Well, you omitted 'various' stuff. I agree that something is calling
>>> back into C when it shouldn't. Are there any function names between
>>> frame 6 and 44 that would give me a clue where we've been negligent?
>>
>> Ah yes, sorry. Here's the full trace:
>>
>> (gdb) where
>> #0 0x0000003c0aa0af19 in pthread_cond_wait@@GLIBC_2.3.2 () from
>> /lib64/libpthread.so.0
>> #1 0x00000000005ac6e9 in waitCondition ()
>> #2 0x00000000005c67ab in waitForReturnCapability ()
>> #3 0x00000000005a3f17 in rts_lock ()
>> #4 0x00000000004ce397 in SystemziGlibziGObject_d1wV ()
>> #5 0x0000003c10cd8eed in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
>> #6 0x0000003c0ba0d6a8 in g_object_unref () from /lib64/libgobject-2.0.so.0
>> #7 0x0000003c10ccebc7 in gtk_tree_view_remove_column () from
>
> I understand now where this error is. There is a call in your program to
> cellLayoutSetAttributes. This function installs certain callbacks that
> Gtk+ tries to free in the stack trace above. The call stack above is
> triggered by
>
>> #41 0x0000003c0ba0d632 in g_object_unref ()
> from /lib64/libgobject-2.0.so.0
>> #42 0x00000000005abdfd in runAllCFinalizers ()
>
> ... and I suppose runAllCFinalizers is the GC and an 'unsafe' call from
> Haskell. Thus, it is actually only possible to use the C function
> freeHaskellPtr. I do that now.
>
>
>> (3) use Haskell finalizers with idleAdd as a temporary workaround.
>>
>> (3) is by far the easiest solution, but it may have unacceptable
>> performance, I'd interested to know if that's the case. The runtime
>> does batch multiple finalizers so they don't each get a separate Haskell
>> thread, so it might not be too bad.
>>
>> I'm not completely averse to doing (1) if it's absolutely necessary, but
>> I'd like to do something that avoids having a dependency on a future
>> version of GHC. And all things being equal, we should avoid adding new
>> features to GHC because they're hard to remove again.
>
> So now there are two kinds of finalizers:
>
> (1) those that directly free the C GObject which are used in Cairo and
> (in the future) Pango, Pixbuf, and all other libraries whose objects do
> not call back into Haskell.
>
> (2) all finalizers of Gtk+ and libraries that build upon Gtk+
> (sourceview, etc). These call a special finalizer that enqueues the
> object to be finalized into an array and install a an g_idle_add handler
> that will run the finalizers from the main iteration loop of Gtk+ and,
> thus, from the right thread and from a safe call.
>
> All objects in (2) can therefore call back to Haskell while they are
> being destroyed. I have therefore moved the possibility to add a WeakRef
> (a function that is called when a GObject is finalized) to from GObject
> to Graphics.UI.Gtk.Abstract.Object which means they can only be
> installed on objects that fall into category (2).
>
> So the darcs version of Gtk2Hs with -threaded should now work as
> expected. You're still responsible to call Gtk2Hs function from the same
> Haskell thread. But you can create Cairo drawings and Pagno stuff in
> different threads and pass them to the main thread.
>
> Cheers,
> Axel.
>
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
