Re: gdk threads enter/leave not enough?

Felix Kater wrote:
Tristan Van Berkom <tristan van berkom gmail com> wrote:

I never call gtk+ directly but have my own wrappers which take care of
gdk_threads_enter/leave. So I am sure I haven't forgotton it somewhere.

This could be dangerous, you'll deadlock if you call threads_enter from
a signal handler that was launched by a gtk+ widget (because the lock
has to be already aquired for the signal to be dispatched).

Ok, I see, however, in win32 this works. It's strange but true. I
remember, though, that trying my gtk/win32 code on a linux machine did
end up in a deadlock. Thanks again for pointing that out, however, this
is probably not the reason here.

    we nailed it then, if your app locks up on a system/installation
that is respecting the gdk_threads_mutex but doesnt on your windows
installation, then calls to gtk/gdk arent waiting for the lock;
landing us in the infamous land of "unpredicted behaviour".

Soooo, the question now is why doesn't the lock work on your system ?
Do other GMutex's work ? or is it just gdk_threads_mutex that doesnt ?

But what do you mean by "including the parent"? Do I have to wrap something
into gdk_threads_enter/leave additionally to the gtk+ calls?

I mean including the the process that called g_thread_create().

Maybe this is the solution (?). But I don't get the point... Why should
I wrap the parent process into gdk_threads_enter/leave? And, what
should I wrap? The whole process or only the call to g_thread_create?
But this hasn't got anything to do with gtk+, has it?

No no no,
     this is just a simple misunderstanding, in your original mail
you wrote:

> my applications crash if I wrap gtk/gdk function calls from threads
> into gdk_threads_enter/leave only.

I just wanted to make sure that all calls to gtk/gdk we're called inside
the lock, not just the "calls from threads /only/", the terminolagy may
be a little complicated, when my process calls g_thread_create(); it
creates a thread, but it also /is/ a thread in the resulting
multi-threaded application, as long as /all/ threads respect the lock;
everything should go well.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]