(speaking from a position of zero knowledge of LO's threading
stuff, but having spent way too much time chasing threading gunk
in general ..)
Michael Meeks wrote:
> > So - I'm with Kohei mostly - lets not do over-expensive,
> > non-inline-able nonsense atomic operations when we don't need to.
Michael Meeks wrote:
> FWIW - the bogus and over-granular threading approach in existing
> LibreOffice code is something that needs beating to death.
> LibreOffice threading: "inspired by the java synchronized" keyword is a
> nightmare.
>
True - but:
> So - I'm with Kohei mostly - let
On Tue, 2011-04-26 at 14:57 -0400, Kohei Yoshida wrote:
> Making stuff thread-safe comes with an overhead, and in some code
> thread-safety isn't really guaranteed, like Calc core.
FWIW - the bogus and over-granular threading approach in existing
LibreOffice code is something that needs b
On Tue, 2011-04-26 at 20:47 +0200, Thorsten Behrens wrote:
> Rafael Dominguez wrote:
> > [...] so my question is should the ref count be thread safe or
> > not?
> >
> Yes, it'll have to. LibO core objects tend to get used from
> different threads simultaneously - at least it's truly hard to
> verif
Rafael Dominguez wrote:
> [...] so my question is should the ref count be thread safe or
> not?
>
Yes, it'll have to. LibO core objects tend to get used from
different threads simultaneously - at least it's truly hard to
verify they're not.
Cheers,
-- Thorsten
pgpVyWIbsEuVd.pgp
Description: PGP
I was talking to kohei about porting this macros
http://opengrok.libreoffice.org/xref/libs-gui/tools/inc/tools/ref.hxx to
their smart pointer equivalent, he suggested using intrusive_ptr for it and
as you all know you need to provide your own ref counting functions, like he
did in here
http://openg
