On Mon, Aug 6, 2012 at 1:28 PM, Pavel Holejsovsky
pavel.holejsov...@gmail.com wrote:
[ ... ]
Pavel, on re-reading Colin's bug report and then your original message, I
realize that I was not paying attention. You were discussing object cleanup
from GC in non-main-event-loop threads, not
On Mon, 2012-08-06 at 16:44 -0400, Colin Walters wrote:
https://bugzilla.gnome.org/show_bug.cgi?id=681334
This bug is now updated with a new patch.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Mon, Aug 6, 2012 at 11:08 AM, Pavel Holejsovsky
pavel.holejsov...@gmail.com wrote:
[ ... ]
Sorry for not being clear. I wanted to say that previously, when higher
language registered callback or signal, it didn't have to bother whether
the callback or signal will be called with proper
On Mon, 06 Aug 2012 11:56:48 -0400, Paul Davis wrote:
i don't believe that there are any examples in glib/gdk/gtk where a
signal handler attached to a signal of a glib/gdk/gtk object will be
executed in anything other than the main event loop. glib/gdk/gtk
doesn't contain any thread tunneling
On Mon, 2012-08-06 at 17:28 +, Pavel Holejsovsky wrote:
And AFAIK you will get
callbacks from worker threads when using asynchronous Gio operations.
There may or may not be a worker thread behind the scenes, but gio will
use the thread-default main context in use at the time the function
are working with gstreamer. And AFAIK you will get
callbacks from worker threads when using asynchronous Gio operations.
the title of this thread is deprecating GDK threads.
nothing stops anyone from using other mechanisms (including those in glib)
to handle synchronization. the issue
On Mon, 06 Aug 2012 13:36:50 -0400, Colin Walters wrote:
There may or may not be a worker thread behind the scenes, but gio will
use the thread-default main context in use at the time the function was
initially invoked.
Oh, thanks for the correction, so the situation is much better than I
On Mon, 2012-08-06 at 17:08 +0200, Pavel Holejsovsky wrote:
Basically, we define well-known ID for storing MainContext into any
gobject's data slot (g_object_set_data). It is up to implementation
(i.e. GTK/GDK/Clutter) to store an appropriate GMainContext instance to
this slot, marking
On Mon, 06 Aug 2012 13:42:35 -0400, Colin Walters wrote:
This raises the question what main context? I'd suggest that GTK
should store the result of g_main_context_get_thread_default() when
gtk_init() is called.
Also, how does the object slot get set? Add it to _constructed for
each
On 08/06/2012 05:56 PM, Paul Davis wrote:
i don't believe that there are any examples in glib/gdk/gtk where a
signal handler attached to a signal of a glib/gdk/gtk object will be
executed in anything other than the main event loop.
Does GIO count? Off the top of my head:
*
On Mon, Aug 6, 2012 at 3:54 PM, Stef Walter st...@gnome.org wrote:
On 08/06/2012 05:56 PM, Paul Davis wrote:
i don't believe that there are any examples in glib/gdk/gtk where a
signal handler attached to a signal of a glib/gdk/gtk object will be
executed in anything other than the main
On Mon, 2012-08-06 at 17:52 +, Pavel Holejsovsky wrote:
This is nice, much more lightweight, and does not use per-object slot.
The only drawback is that it must be done manually in the whole gdk/gtk/
clutter. But it might not actually be that big drawback.
Untested demonstration patch:
On Sat, 2012-08-04 at 09:51 -0400, Matthias Clasen wrote:
If your application doesn't call gdk_threads_init or
gdk_threads_set_lock_functions, there's no need to use enter/leave.
Libraries are a different story, of course.
Would that also imply there's no need to use gdk_threads_add_idle(),
On Fri 03 Aug 2012 16:24, Pavel Holejsovsky pavel.holejsov...@gmail.com
writes:
I'd like to bring up the issue of how language bindings should cope with
this.
It is indeed pretty nasty, especially if you got used to a solution like
the java-gnome one.
One way to solve this would be to put
of any thread and application/binding has generally little control
over this.
AFAICS, this does not play nice with gdk threads deprecation, because one
way to solve the GC finalization problems was to gdk_threads_enter() before
entering g_object_unref() call.
that would have only worked
g_object_unref()) can be
invoked in the context of any thread and application/binding has
generally little control over this.
AFAICS, this does not play nice with gdk threads deprecation, because
one way to solve the GC finalization problems was to gdk_threads_enter()
before entering g_object_unref() call
I've put patches for deprecating the gdk threading api at
https://bugzilla.gnome.org/show_bug.cgi?id=680754
Review appreciated.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi Paul,
On Mon, 2012-05-21 at 09:14 -0400, Paul Davis wrote:
its really not significantly different from g_idle_add(), except that
SendMessage relies on a switch()
Notice - we get a return value, without needing to create a manual
condition, wait on it, signal it, and pass pointer to
Hi Stef,
On Tue, 2012-05-22 at 12:19 +0200, Stef Walter wrote:
On 05/21/2012 04:18 PM, Paul Davis wrote:
That claim sounds really strange; since - well - we do that in
LibreOffice ourselves :-)
...
Michael, it may just happen that the GTK calls you've seen being
performed
On Tue, 2012-05-22 at 16:07 +0200, Stef Walter wrote:
If you have more details/links on how VCL gets around this, I'd be
interested. A bit of a morbid curiosity perhaps :P
Sure; here is some of it:
On 05/22/2012 04:46 PM, Michael Meeks wrote:
On Tue, 2012-05-22 at 16:07 +0200, Stef Walter wrote:
If you have more details/links on how VCL gets around this, I'd be
interested. A bit of a morbid curiosity perhaps :P
Sure; here is some of it:
On 05/22/2012 01:56 AM, Benjamin Otte wrote:
Michael Meeksmichael.meeksat suse.com writes:
The unfortunate thing about
this design is that every toolkit user gets to re-write a bus-load of
boiler plate stubs skels and link them into every application. Why not
do that, just in a better way,
On 05/21/2012 04:18 PM, Paul Davis wrote:
On Mon, May 21, 2012 at 9:39 AM, Michael Meeks
michael.me...@suse.com wrote:
That claim sounds really strange; since - well - we do that in
LibreOffice ourselves :-)
Windows does not allow you to process events/messages for a
On 05/22/2012 01:03 PM, Michael Meeks wrote:
Even if you get the locking right -- even if absolutely only one
thread is executing at once in your process -- like Paul said, you still
get behavior that at a minimum freezes your window, and in other cases
can act a lot like memory corruption.
On Mon, May 21, 2012 at 7:36 AM, Michael Meeks michael.me...@suse.comwrote:
So - yes, the solution of:
* simply re-write -all- your code to make everything call
asynchronous / idle handlers on one-of-N glib mainloops
Has the siren of simplicity for gtk+
On Mon, May 21, 2012 at 9:00 AM, Michael Meeks michael.me...@suse.comwrote:
Windows, has this rather nice 'SendMessage' abstraction that hides
that
synchronous cross-thread blocking fun,
its really not significantly different from g_idle_add(), except that
SendMessage relies on a
Hi Paul,
On Wed, 2012-04-25 at 09:05 -0400, Paul Davis wrote:
there seems to be some confusion here. I've read back over your posts
in the this thread. I don't see you mentioning libreoffice doing
anything that requires thread enter/leave calls.
Heh :-) sorry for the slow rate of
Hi Paul,
On Mon, 2012-05-21 at 08:03 -0400, Paul Davis wrote:
your code must have an event loop abstraction, at some level. if it
doesn't then in 2012 there's nothing else to talk about, really.
Of course it has an event loop abstraction, it has had that for decades
- it's not as clean
On Mon, May 21, 2012 at 9:39 AM, Michael Meeks michael.me...@suse.comwrote:
your code is designed around the execution of GDK/GTK code in multiple
threads. it was unfortunate that GDK/GTK ever allowed this (as has
been pointed out, this is absolutely NOT possible on Windows with
Michael Meeks michael.meeks at suse.com writes:
The unfortunate thing about
this design is that every toolkit user gets to re-write a bus-load of
boiler plate stubs skels and link them into every application. Why not
do that, just in a better way, inside the toolkit ?
(Disclaimer: This
On Mon, 2012-03-05 at 13:16 -0500, Ryan Lortie wrote:
To point at something concrete: attempting to use GTK on Windows from
something other than the main thread will result in bad behaviour (even
if you're holding the GDK lock) because Windows doesn't like you
interacting with a window from a
On Wed, Apr 18, 2012 at 6:24 AM, Michael Meeks michael.me...@suse.com wrote:
[... ]
there seems to be some confusion here. I've read back over your posts
in the this thread. I don't see you mentioning libreoffice doing
anything that requires thread enter/leave calls. You've mentioned idle
On Wed, 25 Apr 2012 09:05:47 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
On Wed, Apr 18, 2012 at 6:24 AM, Michael Meek
michael.me...@suse.com wrote: [... ]
there seems to be some confusion here. I've read back over your posts
in the this thread. I don't see you mentioning libreoffice
On Wed, Apr 25, 2012 at 1:53 PM, Chris Vine ch...@cvine.freeserve.co.uk wrote:
That's interesting - you have found with Ardour that attaching timeout
sources to a main loop is not thread safe?
Not at all - we just don't want it. The other event loops run/provide
support for non-Graphical UIs,
On Wed, Apr 25, 2012 at 2:36 PM, Chris Vine ch...@cvine.freeserve.co.uk wrote:
I was responding to your advice that If you want other threads to be
able to set up timeout callbacks in the GUI event loop, then just use
g_idle_add() to get them set up. Something seems to have become
elided in
On Wed, 25 Apr 2012 14:39:24 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
i've never seen anyone remark that attaching a timeout (or other
source) to a main loop is thread safe. if it is, then great. i was
under the impression that g_idle_add() was special ...
All the main loop sources
On Wed, Apr 25, 2012 at 2:50 PM, Chris Vine ch...@cvine.freeserve.co.uk wrote:
On Wed, 25 Apr 2012 14:39:24 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
i've never seen anyone remark that attaching a timeout (or other
source) to a main loop is thread safe. if it is, then great. i was
On Wed, 25 Apr 2012 15:10:18 -0400
the issue is not the source. its *attaching* it that is the potential
source of problems. g_source_attach()'s docs make no mention of
whether it can be done safely from another thread. that's also true of
the layers above it like g_timeout_add() etc.
where
On Wed, Apr 25, 2012 at 3:28 PM, Chris Vine ch...@cvine.freeserve.co.uk wrote:
If g_source_attach() is not thread safe, then g_idle_add() is not
threads safe: it invokes g_source_attach() in the same way that the
other *_add()'s do. Idle sources are just another source, albeit ones
which fire
On Wed, 25 Apr 2012 20:28:31 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
The documentation states: GLib itself is internally completely
thread-safe (all global data is automatically locked), but individual
data structure instances are not automatically locked for performance
reasons.
On Wed, 2012-04-11 at 11:28 -0400, Paul Davis wrote:
On Wed, Apr 11, 2012 at 7:26 AM, Paul Davis p...@linuxaudiosystems.com
wrote:
Are there any plans for a gtkmm release based on gtk2 that will avoid
the endless messages about using deprecated API, some related to
thread stuff in gtk
and ensure that events / idle / timeout emissions
hooked in by the toolkit can have applications add lock/unlock pairs ?
We're not removing -- only deprecating.
The deprecation does not seem to have happened in GTK+ 3.4:
http://developer.gnome.org/gdk3/3.4/gdk3-Threads.html#gdk-threads-enter
Are there any plans for a gtkmm release based on gtk2 that will avoid
the endless messages about using deprecated API, some related to
thread stuff in gtk 2.24?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
:
http://developer.gnome.org/gdk3/3.4/gdk3-Threads.html#gdk-threads-enter
Is it still planned?
Yes - it wasn't planned for 3.4 - we'll do it once we branch (ie next week)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org
On Wed, Apr 11, 2012 at 7:26 AM, Paul Davis p...@linuxaudiosystems.com wrote:
Are there any plans for a gtkmm release based on gtk2 that will avoid
the endless messages about using deprecated API, some related to
thread stuff in gtk 2.24?
these, specifically, are the messages i'm referring to:
Hi guys,
Just a quick sanity check, I noted Ryan's blog mentioned:
we’re going to deprecate gdk threads next cycle. (yay!)
Does that mean you're removing gdk_threads_enter and leave and the
semantics around that ? is there some cunning new scheme proposed to
intercept
On Mon, 2012-03-05 at 14:07 +, Emmanuele Bassi wrote:
On 5 March 2012 13:07, Ryan Lortie de...@desrt.ca wrote:
The removal will come in GTK4. There will be no replacement
functionality -- you will just be expected to do all your interaction
with the toolkit from the main thread (ie:
probably be established and run until the dialog itself
is destroyed.
I'd like some input on what's the best and most (thread-)safe way to set up
the main loop or if there are any other options to avoid using GDK threads
calls and make the implementation future-complaint today.
Best regards,
Zan
[1
or similar workarounds as with
gtk_dialog_run), meaning a main loop should probably be established
and run until the dialog itself is destroyed.
I'd like some input on what's the best and most (thread-)safe way to
set up the main loop or if there are any other options to avoid using
GDK threads
hi Michael,
On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote:
Does that mean you're removing gdk_threads_enter and leave and the
semantics around that ? is there some cunning new scheme proposed to
intercept the mainloop and ensure that events / idle / timeout emissions
hooked in
Heya,
On Mon 05 Mar 2012 14:07, Ryan Lortie de...@desrt.ca writes:
On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote:
Does that mean you're removing gdk_threads_enter and leave and the
semantics around that ? is there some cunning new scheme proposed to
intercept the mainloop and
On Mon, Mar 5, 2012 at 9:34 AM, Andy Wingo wi...@pobox.com wrote:
Heya,
On Mon 05 Mar 2012 14:07, Ryan Lortie de...@desrt.ca writes:
On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote:
Does that mean you're removing gdk_threads_enter and leave and the
semantics around that ? is
Hi.
Many applications use the following loop:
/* START */
while (gtk_events_pending())
gtk_main_iteration();
/* END */
This loop is also there in Gaim. But this started causing problems when
gdk_threads_init() was introduced to the code. The problem is: when this
loop is executed while a
Felix Kater wrote:
Tristan Van Berkom [EMAIL PROTECTED] 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
First, thanks again for your answer!
Tristan Van Berkom [EMAIL PROTECTED] 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
Felix Kater wrote:
[...]
b. It is not possible to savely call gtk/gdk functions from different
threads using gdk_threads_enter/leave only (see my original post). In this
case a thread enters gdk_threads_enter() although is shouldn't. My
workaround: Use flags and let gtk functions be called from
Fe Kater wrote:
This sounds very strange, are you wrapping all your gtk+ api accessing
code in enter/leave in all threads (including the parent) and only
from event sources (i.e. not in signal handlers that are fired by gtk
widgets) ?
I never call gtk+ directly but have my own wrappers
57 matches
Mail list logo
