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, anyway, you cannot allow for editing, otherwise you need to
make the whole LyX thread-safe, something you don't want absolutely to do.
In my old patch for ESC-based abortion of search, I used to keep calling
repeatedly some Qt function to know whether the user had pressed ESC.
Probably by "GUI responsive" you're meaning the ability to e.g., scroll
the document and/or redraw/repaint parts of the window, right ?
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 improving design or whatever, but merely for speeding up the
search process in case you have multiple cores (I know, you'll keep
criticizing me that there's another way to improve by improving the
sequential part of the algorithm, but as I said exploiting the available
CPUs is just another way and does not preclude to improve the sequential
search as well -- if I had time, I'd try to parallelize also the export
and ps/pdf preview, if possible, as it seems quite time-consuming as
well [perhaps we cannot parallelize latex, but at least calling all the
converters...]).
I think we need to be ready to write more and more code in a parallel
fashion. Each and every time I see any application letting me wait due
to expensive computations, and I see from the CPU monitor that only 1
core is being used, I re-think again & again that the hardware-software
gap is becoming really huge, and software is development is really
struggling at following the developments of (event the cheap) hardware.
First, I don't think your patch is small. Second, the need for mutexes
is often a sign that something is wrong in the architecture.
... and this statement about mutexes is outside of my comprehension.
Here I'm not composing independent UniX processes via pipes or whatever.
I'm just coordinating multiple threads in deciding which part/paragraph
of the same document needs to be searched next. You cannot decide in
advance how to split the search across cores, because paragraphs have
different lengths and it takes different times to search across them.
What else rather than mutexes would you use for such a job ? I hope
you're not referring to lock-free synchronization . . .
Who said that we should rewrite from scratch? You could begin at least
with Paragraphs. Then one inset at the time. I believe the code will
hugely benefits from this work as we would then have means to compare
easily and effciently two paragraphs, two insets, etc. I guess that
could be useful for Change-Tracking for example.
But I'd need to understand all the internal fields of all the insets,
and add a comparator method that, depending on the selected options into
the FindAdvOpt structure, decides which ones of these fields to exactly
compare and how..... easy to do for a few insets, but can you see how
many insets LyX has :-) ?
I'm not sure, but perhaps the recently realized document comparison by
Vincent may provide an idea of the required effort ? Also, anything
reusable from that feature ?
T.
