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
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
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 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
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
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 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
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 t
Hi there,
On Fri, 2011-03-25 at 14:47 +, Michael Meeks wrote:
> I'll build a package to test your patch in a second too.
Well - the patch solves the problem for me; inasmuch as I can no longer
make it crash (or assert fail) like it used to. Also - if I tweak it to:
Hi Alex,
On Fri, 2011-03-25 at 12:28 +0100, Alexander Larsson wrote:
> I had a look, and its not true that none take the lock, they just call
> gdk_threads_enter() directly, not the GDK_THREADS_ENTER macro. However,
> there were quite a few places that had it missing.
Ah - fair enough; I
Hi guys,
I was just digging into a libreoffice assertion failure when using the
gtk+ file selector:
Gtk:ERROR:gtkfilesystemmodel.c:746:gtk_file_system_model_sort: assertion
failed: (r == n_visible_rows)
which looked to me, like it could well be a thread related issue; in
particul
Hi David,
On Wed, 2010-08-11 at 08:48 -0400, David Zeuthen wrote:
> (Wouldn't it have been better to file this in bugzilla?)
As you like; wrt. a multi-pronged discussion of several related issues
and deepen at least my understanding, so I thought here might be good
but ...
> >Is
Hi there,
After the mythically curious dbus socket code [ as Havoc says
~"re-writing it would be easier than understanding it" ] - I was full of
enthusiasm for the new gdbus.
The new code, while more readable and promising, seems to have a few
drop-offs. The first I noticed was ge
Hi there,
On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:
> I think that we are now at a place where its used widely enough and
> is important enough that we need to be able to rely on the basic
> threading primitives in our libraries and plugins by default. It
> would be nice to be ab
Hi Ryan,
On Thu, 2010-02-25 at 18:17 -0500, Ryan Lortie wrote:
> Thanks for catching this. This is truly an impressive bug. I'm
> surprised you were able to track it down -- I hope it didn't take too
> much time. :)
Lol - my machine has a death-wish obviously.
> I fixed the issue you c
On Thu, 2010-02-25 at 21:31 +, Michael Meeks wrote:
> I'm also getting some other really unusual memory corruption goodness,
> that is just too fun :-) of course running under valgrind hides the
> races so it doesn't happen anymore.
Phew - turns out, after some
Hi there,
Just trying to get GDBus into a good state for evolution; and I was
(still am) getting some really tangled threading crashers :-) exciting
stuff.
One of them is from the slightly unfortunate weak-reference /
hash-table scheme in gvarianttypeinfo.c (patch attached). Of co
On Fri, 2009-11-20 at 14:02 +0100, Alexander Larsson wrote:
> > it was fixed a very long time ago. The problem, as you note, is with
> > everything above libglib in the stack, not with libglib itself.
>
> We really need to get our story together here. Either we do our very
> best to handle late g_
Hi Tristan,
On Mon, 2009-11-16 at 14:34 -0200, Tristan Van Berkom wrote:
> > Michael wrote:
> > fact by the threading system ? [ I was never persuaded that glib's
> > demand to initialize threads before any other line of code was remotely
> > reasonable either BTW ;-]
>
> Its really very simple.
On Thu, 2009-11-12 at 16:36 +, Michael Meeks wrote:
> b) there are simple, more robust ways to indirect the 250 or so
> method calls that are thread sensitive via a single vtable
Hmm, so - having written all that nonsense - I read the glibc code; and
incredibly i
> > This would definitely be the nicest solution, but I doubt that it is
> > possible.
So - this whole issue is just horrific.
> Michael Meeks could know more about the interposing and maybe propose
> better fix for gmodule, gtk or gio.
There is basically no good f
On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote:
> The debate is far from over with this. gio should be made slower and do
> unnecessary syncronous I/O in order to fulfill the standards, yes.
Sure, it should fsync on ext4-before-it-was-fixed systems - it sucks to
loose data; th
Hi Alex,
On Fri, 2009-03-13 at 08:38 +0100, Alexander Larsson wrote:
> If you want to you can make all i/o sync by mounting it as such. But
> thats of course really slow. Generally the gio file write operations are
> used for saving files, and people sort of expect that when save returns
> the fil
On Thu, 2009-03-12 at 21:11 +0100, Alexander Larsson wrote:
> With all the recent yahoo about ext4 data loss and fsync I felt I had to
> look at glib and make sure we're doing this right.
Hmm; is this not just a database guy ? ;-) presumably if -all- file I/O
should be synchronous, the ke
Hi Owen,
On Thu, 2007-03-15 at 11:55 -0400, Owen Taylor wrote:
..
> For your purposes, you'd probably be better off modifying your patch
> so that the call to _gdk_events_init() was skipped, but that returns
> you to having a GDK with a number of things that don't quite work (not
> counting the b
Hi Tim,
On Thu, 2007-01-04 at 12:56 +0100, Tim Janik wrote:
> which is exactly the problem. *if* we support it, we need to *fully* do
> that, i.e. keep supporting it.
Nah; there is no need to fully support it, merely behaving like we did
in the past would be adequate for the legacy tail o
Hi there,
On Tue, 2007-01-02 at 14:34 +0100, Tim Janik wrote:
> since the very early inception of the glib threading system, the docs
> say ( http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html ):
> You must call g_thread_init() before executing any other GLib
> functions in
On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote:
> > In essence the timeout is way too short for switching days; also -
> > in the panel applet the timeout has a higher priority than the
> > queued resize of the display (and hence the redraw) - so in
> > essence we skip days even
On Wed, 2006-02-08 at 18:01 +0800, James Henstridge wrote:
> > :-) Either way - there is a workaround now; and as Federico says prolly
> >going via the environment is a more robust & cleaner solution.
>
> The only issue with using the environment is that it is inherited by
> child processes.
On Tue, 2006-02-07 at 17:04 -0500, Owen Taylor wrote:
> I have vague memory that modules not getting arguments is intentional
> rather than an oversight ... that we discussed it at the point of the
> GOption switch and decided it was fundamentally busted and
> unsupportable.
>
> I may just be inv
On Tue, 2006-02-07 at 09:24 -0500, Matthias Clasen wrote:
> > Unfortunately - the introduction of GOption clobbered all GtkModule
> > argument passing; and ensures that no GtkModule gets anything but a
> > 0/NULL argc/argv cf.
>
> Looks like this is a bug that got introduced when we first
Hi there,
So - I've been chasing a rather interesting bug:
"GNOME hangs on login with a11y enabled"
Of course - clobbering the proximate cause: gnome-session activating
vino-server synchronously works around this nicely; but there is a
deeper problem:
Wh
On Tue, 2005-12-27 at 19:15 -0500, Owen Taylor wrote:
> > + * g_main_context_is_owner:
..
> This looks simple and straightforward enough that I'm OK with it being
> added even if it is very specialized.
Thanks - committed,
Regards,
Michael.
--
[EMAIL PROTECTED
Hi Owen,
On Thu, 2005-12-22 at 13:04 -0500, Owen Taylor wrote:
> + * If the current thread is the owner of @context returns
> + * TRUE else FALSE. This is semantically rather different
> + * from acquiring ownership.
>
> Umm, "no duh". :-) It would be much more useful if the docs gave
> some idea
So,
I sent this a while back - but didn't see it on the list - perhaps
broken subscription information (?).
I append a patch implementing these two to some level.
On Thu, 2005-11-17 at 16:57 +0000, michael meeks wrote:
> So - I've been trying to use the GMainC
On Tue, 2005-12-13 at 12:16 -0600, Federico Mena Quintero wrote:
> > So - as part of my -Bdirect work - trying to detect genuine cases of
> > interposing - I ran my simple perl script over all my gnome libraries:
> > http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome
> > s
Hi Alex,
On Tue, 2005-12-13 at 16:31 +0100, Alexander Larsson wrote:
> On Fri, 2005-12-09 at 14:36 +0000, michael meeks wrote:
> > I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least
> > -
> > assuming that does the right thing ) - in all the g_module_op
Hi guys,
So - as part of my -Bdirect work - trying to detect genuine cases of
interposing - I ran my simple perl script over all my gnome libraries:
http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome
specific exclusions file [this incidentally shows lots of other bad
b
Hi guys,
So - I've been trying to use the GMainContext to fix a rather tricky
issue in using unsafe single-threaded code accessed via ORBit2 from
multiple OO.o threads in a safe & reliable way. This is somewhat
involved, for various reasons, but made particularly unpleasant due to 2
missin
39 matches
Mail list logo
