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 p
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
hi;
On 5 March 2012 13:07, Ryan Lortie 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: dispatching results via
> idles).
AFAIR, the java-gnome bindings used
Heya,
On Mon 05 Mar 2012 14:07, Ryan Lortie 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 ensure th
On Mon, Mar 5, 2012 at 9:34 AM, Andy Wingo wrote:
> Heya,
>
> On Mon 05 Mar 2012 14:07, Ryan Lortie 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 ne
hi,
On Mon, 2012-03-05 at 14:58 +, Michael Meeks wrote:
> Ryan: when you say "the main thread" - what does that mean ? does it
> mean from "a single thread" - as in we need to guarentee that the calls
> are only ever actually happening from a single thread at a time ? or
> does it mean t
On Mon, 2012-03-05 at 14:07 +, Emmanuele Bassi wrote:
> On 5 March 2012 13:07, Ryan Lortie 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: dispatchi
Emmanuele Bassi gmail.com> writes:
> I guess we'll have to maintain the gdk_threads_set_lock_functions(),
> and internally use gdk_threads_enter()/_leave(), even if the API is
> not available in public headers.
>
No, we will not.
If you want to use GTK, you will have to ensure that all GTK func
posed to
> > intercept the mainloop 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://d
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://mail.gnome.org/mailman/listinf
-- 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
>
> Is it still planned?
>
Yes - it wasn't planned for 3.4 - we'll do it once we branch (ie next week
On Wed, Apr 11, 2012 at 7:26 AM, Paul Davis 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:
/Users/paul/a3/inst/in
On Wed, 2012-04-11 at 11:28 -0400, Paul Davis wrote:
> On Wed, Apr 11, 2012 at 7:26 AM, Paul Davis
> 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, spec
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 fro
On Wed, Apr 18, 2012 at 6:24 AM, Michael Meeks 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
callbacks, timeout callbacks.
On Wed, 25 Apr 2012 09:05:47 -0400
Paul Davis wrote:
> On Wed, Apr 18, 2012 at 6:24 AM, Michael Meek
> 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/
On Wed, Apr 25, 2012 at 1:53 PM, Chris Vine 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, and they can be
instantia
On Wed, 25 Apr 2012 13:57:46 -0400
Paul Davis wrote:
> On Wed, Apr 25, 2012 at 1:53 PM, Chris Vine
> 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
On Wed, Apr 25, 2012 at 2:36 PM, Chris Vine 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 the telling, since one
On Wed, 25 Apr 2012 14:39:24 -0400
Paul Davis 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 are thread safe (and th
On Wed, Apr 25, 2012 at 2:50 PM, Chris Vine wrote:
> On Wed, 25 Apr 2012 14:39:24 -0400
> Paul Davis 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 spe
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.
>
>
On Wed, Apr 25, 2012 at 3:28 PM, Chris Vine 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 immediately they are re
On Wed, 25 Apr 2012 20:28:31 +0100
Chris Vine 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. For example, you must c
On Mon, May 21, 2012 at 7:36 AM, Michael Meeks wrote:
>
>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+ maintainers to whom ad
On Mon, May 21, 2012 at 9:00 AM, Michael Meeks wrote:
>
>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 switch() on the other
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 re
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 clea
On Mon, May 21, 2012 at 9:39 AM, Michael Meeks wrote:
>
> > 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
> > violating several fund
Michael Meeks 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 is my pers
On 05/22/2012 01:56 AM, Benjamin Otte wrote:
Michael Meeks 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 too
On Tue, May 22, 2012 at 10:59 AM, Martyn Russell wrote:
>
> I've always believed libraries should do the job that *many* projects would
> have to re-implement. It just doesn't make sense from a maintenance and bug
> fixing point of view to have many solutions to the same problem scattered
> around
On 05/21/2012 04:18 PM, Paul Davis wrote:
> On Mon, May 21, 2012 at 9:39 AM, Michael Meeks
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 given window
> in
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 corru
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:
>
> http://cgit.freedesktop.org/l
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
> p
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:
http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/window/salframe.cxx#n
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
ypically invoke 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_obje
On Fri 03 Aug 2012 16:24, Pavel Holejsovsky
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 the burden on the bindings
The good thing is that we have enough time to work this out - GTK+ 4
will not appear overnight.
In the meantime, here are some hints for how to deal with fallout from
the deprecation of GDK_THREADS_ENTER/LEAVE in the short term:
1. There's no point anymore in the macro wrappers
GDK_THREADS_ENTER/
he end, this means that
> finalizers (which typically invoke 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 solv
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(),
the signal (or callback) can
come in some other thread and whether GLib.idle_add() is needed or not.
It is just potential source of bugs when GLib.idle_add() is not used
when it should be.
AFAICS, this does not play nice with gdk threads deprecation, because one
way to solve the GC finalizatio
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 prope
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 tunne
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
" from.
>
> This is true for glib/gdk/gtk. But you will get signals from worker
> threads when you 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 G
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
t
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
> eac
On Mon, 2012-08-06 at 17:28 +, Pavel Holejsovsky wrote:
> 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
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:
* GDBusInterfaceS
On Mon, Aug 6, 2012 at 3:54 PM, Stef Walter 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 event loop.
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 patc
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
https://mail.gnome.org/mailman/listinfo/gtk-
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 anythi
58 matches
Mail list logo
