Tommaso Cucinotta writes:
| Il 07/11/2011 10:55, Lars Gullik Bjønnes ha scritto:
>> Tommaso Cucinotta writes:
>>
>> | +#include
>> | +#include
>> | +#include
>> | +#include
>> | +#include
>>
>> Oh. how I dislike the Qt-fication of lyx...
>
| I know, but as Qt is a strong dependency, it is anyway
Abdelrazak Younes writes:
| On 07/11/2011 10:22, Tommaso Cucinotta wrote:
>> Hi,
>>
>> I just "enjoyed" extending the Find Advanced feature to exploit
>> multi-cores.
>
| What about enjoying to implement the correct solution for the advanced
| find feature? I'm sure you'll much more fun :-P
>
>>
Il 13/11/2011 19:23, Abdelrazak Younes ha scritto:
On 11/11/2011 11:27, Tommaso Cucinotta wrote:
Il 10/11/2011 22:07, Abdelrazak Younes ha scritto:
Threads is not always about using all available processors.
ok, but here I'm really addressing a different problem: I'm not using
threads for im
On 11/11/2011 11:27, Tommaso Cucinotta wrote:
Il 10/11/2011 22:07, Abdelrazak Younes ha scritto:
Actually no. Don't get me wrong, thread are nice and we should use
them whenever needed. In the case of Advanced search, I reckon that
we need only one new thread to keep the UI responsive while the
Il 10/11/2011 22:07, Abdelrazak Younes ha scritto:
Actually no. Don't get me wrong, thread are nice and we should use
them whenever needed. In the case of Advanced search, I reckon that we
need only one new thread to keep the UI responsive while the search is
done in the background.
... but,
On 09/11/2011 13:16, Tommaso Cucinotta wrote:
Il 08/11/2011 21:37, Abdelrazak Younes ha scritto:
Too complicated for my taste :-)
What do you mean by "complicated", here ? Parallel is always more
complicated than sequential. Still, we can't keep living in the
sequential world, I guess you k
What do you mean by "complicated", here ? Parallel is always more
complicated than sequential. Still, we can't keep living in the
sequential world, I guess you know.
This is the wrong way of thinking. We don't need parallelism because we
can't keep living in the sequential world.
Let's put
Il 08/11/2011 21:37, Abdelrazak Younes ha scritto:
On 07/11/2011 10:22, Tommaso Cucinotta wrote:
Hi,
I just "enjoyed" extending the Find Advanced feature to exploit
multi-cores.
What about enjoying to implement the correct solution for the advanced
find feature? I'm sure you'll much more fu
Le 08/11/11 21:37, Abdelrazak Younes a écrit :
On 07/11/2011 10:22, Tommaso Cucinotta wrote:
Hi,
I just "enjoyed" extending the Find Advanced feature to exploit
multi-cores.
What about enjoying to implement the correct solution for the advanced
find feature? I'm sure you'll much more fun :-P
On 07/11/2011 10:22, Tommaso Cucinotta wrote:
Hi,
I just "enjoyed" extending the Find Advanced feature to exploit
multi-cores.
What about enjoying to implement the correct solution for the advanced
find feature? I'm sure you'll much more fun :-P
It exploits QThreadPool to create "worker" t
Il 08/11/2011 18:43, Vincent van Ravesteijn ha scritto:
Op 8-11-2011 0:46, Tommaso Cucinotta schreef:
Any opinion against committing this patch that uses a mutex for
synchronizing LYXERR() output across multiple threads ?
I don't see an absolute need for it. For now, we don't even use
thread
Op 8-11-2011 0:46, Tommaso Cucinotta schreef:
Il 07/11/2011 14:46, Tommaso Cucinotta ha scritto:
However, now I broke compilation of lyxclient which complains with
errors about not knowing anything about #include and you
can imagine what else...
this is fixed in the attached refined version
Il 07/11/2011 14:46, Tommaso Cucinotta ha scritto:
However, now I broke compilation of lyxclient which complains with
errors about not knowing anything about #include and you can
imagine what else...
this is fixed in the attached refined version of the "SMP debugging" patch.
Interestingly, bo
Il 07/11/2011 10:55, Lars Gullik Bjønnes ha scritto:
Tommaso Cucinotta writes:
| +#include
| +#include
| +#include
| +#include
| +#include
Oh. how I dislike the Qt-fication of lyx...
I know, but as Qt is a strong dependency, it is anyway ok to rely on its
portable
extra features, right ? Fo
Il 07/11/2011 10:47, Lars Gullik Bjønnes ha scritto:
Hmm.. if an earlier match is found, the rest of the workers should be
stopped. That is not really hard to do.
Indeed, my plan is to let the other threads self-stop (checking from
time to time the abort/stop condition). Sending a signal to a
Tommaso Cucinotta writes:
| Hi,
>
| I just "enjoyed" extending the Find Advanced feature to exploit multi-cores.
>
| It exploits QThreadPool to create "worker" threads (as many as the
| underlying
| physical CPUs detected by QThreadPool). Each thread searches in a single
| paragraph, then "querie
Tommaso Cucinotta writes:
| Hi,
>
| I just "enjoyed" extending the Find Advanced feature to exploit multi-cores.
>
| It exploits QThreadPool to create "worker" threads (as many as the
| underlying
| physical CPUs detected by QThreadPool). Each thread searches in a single
| paragraph, then "querie
Hi,
I just "enjoyed" extending the Find Advanced feature to exploit multi-cores.
It exploits QThreadPool to create "worker" threads (as many as the
underlying
physical CPUs detected by QThreadPool). Each thread searches in a single
paragraph, then "queries" the next paragraph to be searched fr
18 matches
Mail list logo
