Peter Kümmel wrote:
>> still you need write access for the first run.
>
> Yes, but at that moment the chance is high to be single threaded,
> but in principle we need the lock anyway.
i dont take this argument. one can always say that some threaded collision is
unprobable to happen. if we know abo
On 16.01.2011 20:52, Pavel Sanda wrote:
Peter Kümmel wrote:
threads should be no problem. And making Graph const correct could
be done by simply cache all results.
still you need write access for the first run.
Yes, but at that moment the chance is high to be single threaded,
but in principl
Peter Kümmel wrote:
> threads should be no problem. And making Graph const correct could
> be done by simply cache all results.
still you need write access for the first run.
pavel
On 16.01.2011 20:01, Richard Heck wrote:
On 01/16/2011 06:08 AM, Peter Kümmel wrote:
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
I'm no expert on this stuff, but it looks to me as if the locks are
needed, unless we start copying the Grap
On 01/16/2011 06:08 AM, Peter Kümmel wrote:
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
I'm no expert on this stuff, but it looks to me as if the locks are
needed, unless we start copying the Graph object every time we use it.
That could
HEAD without the locks in Graph.cpp
It's a typical race condition, see output with attached patch:
184 74127768 size 1 , thread:
186 74127768 size 1 , thread:
36 19714232 size 0 , thread:
This means
line 184: thread 74127768 checks if Q is not empty > enter the while loop
line 186: Q is st
Peter Kümmel wrote:
> On 16.01.2011 11:39, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> Found another way to crash lyx:
>>>
>>> Call utf8_to_ucs4 via getStatus and getPath,
>>> but it is not obvious why it crashes here.
>>> See attechments.
>>
>> what was the scenario, which revision of the tree?
On 16.01.2011 11:39, Pavel Sanda wrote:
Peter Kümmel wrote:
Found another way to crash lyx:
Call utf8_to_ucs4 via getStatus and getPath,
but it is not obvious why it crashes here.
See attechments.
what was the scenario, which revision of the tree?
pavel
HEAD without the locks in Graph.cpp
Peter Kümmel wrote:
> Found another way to crash lyx:
>
> Call utf8_to_ucs4 via getStatus and getPath,
> but it is not obvious why it crashes here.
> See attechments.
what was the scenario, which revision of the tree?
pavel
Found another way to crash lyx:
Call utf8_to_ucs4 via getStatus and getPath,
but it is not obvious why it crashes here.
See attechments.
Peter
LyX.exe!std::basic_string,std::allocator >::_Eos(unsigned int _Newsize) Zeile 1954
C++
LyX.exe!std::basic_string,std::allocator >::ap
On 16.01.2011 00:01, Peter Kümmel wrote:
Graph has a container with pointers (vertices_) but now copy constructor,
this could not work.
Checked this again and I was wrong, the pointers must be to internal objects
which are copied by value (there's nor "new" in Graph.cpp, not API with a
pointe
Richard Heck wrote:
> On 01/15/2011 04:54 PM, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> When a thread enters a function which another thread is busy on it hangs
>>> in the lock, if it wouldn't wait the the chaos would become even worse.
>>> The mutex only guaranties that one operation is finish
On 01/15/2011 06:41 PM, Pavel Sanda wrote:
isn't then this graph path bug just sideffect of disabling buffer-view
lfun
too late, ie more threads starts when pressing lot of ctrl+t/d before we
block the lfun. then - instead of crazy safeguarding of graph class we
could just put some block early
On 01/15/2011 05:40 PM, Pavel Sanda wrote:
Peter Kümmel wrote:
OK, when we really need a graph objects for each thread,
then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. thats good. then we share converters var
which has internal gra
On 01/15/2011 05:46 PM, Peter Kümmel wrote:
The data shareing between the Graphs is done in Graph,
there is a static:
Graph::EdgePath const Graph::getPath(int from, int to)
{
Mutex::Locker lock(&mutex_);
static const EdgePath path;
Just an empty path for return value.
rh
On 01/15/2011 04:54 PM, Pavel Sanda wrote:
Peter Kümmel wrote:
When a thread enters a function which another thread is busy on it hangs
in the lock, if it wouldn't wait the the chaos would become even worse.
The mutex only guaranties that one operation is finished before the next
starts.
yep, i
On 01/15/2011 04:06 PM, kuem...@lyx.org wrote:
Author: kuemmel
Date: Sat Jan 15 22:06:28 2011
New Revision: 37222
URL: http://www.lyx.org/trac/changeset/37222
Log:
Fix crash on Windows:
1. open LYX
2. CRTL-N
3. CRTL-D hold D --> crash
Graph must be thread save to fix this.
And for sure, we ne
Peter Kümmel wrote:
> Found something, attached two backtraces from two threads.
aha!!! we touch graph code in getStatus, before entering actual lfun!
> Peter
>
>
> [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder
> fehlen, keine Symbole geladen für ntdll.dll]
Found something, attached two backtraces from two threads.
Peter
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder
fehlen, keine Symbole geladen für ntdll.dll]
ntdll.dll!7731f861()
ntdll.dll!77338c44()
msvcr100d.dll!_unlock(int l
Peter Kümmel wrote:
> I've checked with a counter and there is only one thread. But what I saw
> when editing the code is the auto-save function, this is a candidate for
> the troublemaker.
autosave will never use getPath no?
pavel
On 16.01.2011 00:41, Pavel Sanda wrote:
Peter Kümmel wrote:
Peter, i dont understand one thing. if i try to reproduce Liviu's
problems,
i see that view buttons get disabled when the export is done. that means
that we actually prohibit more threads to run together.
But we update the status bar
Peter Kümmel wrote:
>> Peter, i dont understand one thing. if i try to reproduce Liviu's
>> problems,
>> i see that view buttons get disabled when the export is done. that means
>> that we actually prohibit more threads to run together.
>
> But we update the status bar or the progress widget while
On 16.01.2011 00:25, Pavel Sanda wrote:
Peter Kümmel wrote:
On 15.01.2011 23:40, Pavel Sanda wrote:
Peter Kümmel wrote:
OK, when we really need a graph objects for each thread,
then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. tha
Peter Kümmel wrote:
> On 15.01.2011 23:40, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> OK, when we really need a graph objects for each thread,
>>> then my patch is wrong.
>>
>> looking at the code it seems, that each export routine has its
>> own local path variable. thats good. then we share co
On 15.01.2011 23:40, Pavel Sanda wrote:
Peter Kümmel wrote:
OK, when we really need a graph objects for each thread,
then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. thats good. then we share converters var
which has internal graph
On 15.01.2011 23:46, Peter Kümmel wrote:
On 15.01.2011 23:40, Pavel Sanda wrote:
Peter Kümmel wrote:
OK, when we really need a graph objects for each thread,
then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. thats good. then we sha
On 15.01.2011 23:40, Pavel Sanda wrote:
Peter Kümmel wrote:
OK, when we really need a graph objects for each thread,
then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. thats good. then we share converters var
which has internal graph
Peter Kümmel wrote:
> OK, when we really need a graph objects for each thread,
> then my patch is wrong.
looking at the code it seems, that each export routine has its
own local path variable. thats good. then we share converters var
which has internal graph G_ and routines around it. if there
is
On 15.01.2011 22:54, Pavel Sanda wrote:
Peter Kümmel wrote:
When a thread enters a function which another thread is busy on it hangs
in the lock, if it wouldn't wait the the chaos would become even worse.
The mutex only guaranties that one operation is finished before the next
starts.
yep, i k
Peter Kümmel wrote:
> When a thread enters a function which another thread is busy on it hangs
> in the lock, if it wouldn't wait the the chaos would become even worse.
> The mutex only guaranties that one operation is finished before the next
> starts.
yep, i know whot is mutex for. my question
On 15.01.2011 22:20, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Sat Jan 15 22:06:28 2011
New Revision: 37222
URL: http://www.lyx.org/trac/changeset/37222
Log:
Fix crash on Windows:
1. open LYX
2. CRTL-N
3. CRTL-D hold D --> crash
Graph must be thread save to fix this.
c
kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Sat Jan 15 22:06:28 2011
> New Revision: 37222
> URL: http://www.lyx.org/trac/changeset/37222
>
> Log:
> Fix crash on Windows:
> 1. open LYX
> 2. CRTL-N
> 3. CRTL-D hold D --> crash
>
> Graph must be thread save to fix this.
can you be more verbos
32 matches
Mail list logo
