<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks!<br>That was really useful!<br><br>I wanted to share my approach to this project with the hope that you can give me some feedback.<br><br>I am think that applying a design that foresees the incorporation of new file formats is the most suitable way to solve the problem.<br><br>In the attached sketch we can see:<br>* Bug_Box: It is responsible for encapsulating and handling errors.<br>* File_extrator: It presents an interface for the different formats.<br>* File_X: Encapsulates a particular library for the X file format.<br>* File_Hadle: It is responsible for directing the extraction. More specifically, it determines the file format and which extractor to use.<br>* Ominex: It represents the rest of the project.<br><br>The idea of organizing the code in this way focuses on two fundamental items:<br>* The possibility of changing a particular library for another that fulfills the same purpose without affecting the project.<br>* The possibility of extending Xapian's support in terms of file format.<br><br>One of the major advantages is that if a particular programmer wishes to add support for a new file format or improve an existing one, they should only modify the objects that are in red. In this way, with a proper documentation this kind of tasks should not be a complex task.<br><br>I know it is an ambitious approach, but I think that with a good documentation it would give the project great flexibility and the programmers would have the option of adapting Xapian to their needs.<br><br>**The image only presents a simple scheme to explain the idea, I do not consider it as a design for the project. I believe that we should discuss about different design patterns to choose the most suitable one.<br><br>Cheers,<br>   Bruno Baruffaldi<br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El sáb., 23 de mar. de 2019 a la(s) 12:10, Olly Betts (<a href="mailto:olly@survex.com">olly@survex.com</a>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Mar 21, 2019 at 09:31:26AM -0300, Bruno Baruffaldi wrote:<br>
> Firstly, I think that trying to isolate library bugs in subprocesses could<br>
> get to work, but I am not sure about how to handle deadlocks or infinite<br>
> loops. I feel that using a timer is the only way to deal with it but I<br>
> would like to know what you think about it.<br>
<br>
There's already code to set a CPU time limit for filter subprocesses<br>
(using setrlimit()) and to implement an inactivity timeout (by using<br>
select() to wait for the connection file descriptor to become readable<br>
or a timeout to be reached) - see runfilter.cc.  I think both mechanisms<br>
should be usable for this project (the CPU time limit would need to<br>
allow for CPU time used by the child process processing previous<br>
files).<br>
<br>
> Secondly, I have been reading the source code of ominex, but I cannot<br>
> figure out if it is possible to group all file formats under the same<br>
> interface. When indexing files, are all file formats treated in a similar<br>
> way, or are there special formats that require a different work (beyond the<br>
> use of external filters)?<br>
<br>
A few do - e.g. for PDF files we currently need to run pdfinfo and<br>
pdftotext on the file, PostScript files are first converted to a<br>
temporary PDF (because there doesn't seem to be a Unicode-aware<br>
filter which converts PostScript to text), etc.<br>
<br>
It may be possible to come up with a common interface still though.<br>
<br>
> To sum up, I want to know if ominex use multithreading for indexing files<br>
> or if you consider that it could be implemented to speed it up.<br>
<br>
Currently there isn't really any parallelism in omindex.  It would help<br>
when indexing formats which are CPU intensive to extract text from<br>
(an extreme case is if you're running OCR to index image files).<br>
<br>
When dealing with external filters, the extra isolation that<br>
subprocesses gives us makes that a better approach than launching<br>
threads - if a library used by a thread crashes the process then the<br>
indexer dies, while if that happens in a subprocess the parent indexer<br>
process can recover easily.<br>
<br>
Potentially we could have concurrent child processes working on<br>
different documents.  I'd suggest that it's better to focus on getting<br>
the subprocesses to work individually first before trying to get them to<br>
run in parallel, but to keep in mind that we're likely to want to<br>
instantiate multiple concurrent instances while implementing them.<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Atte. Bruno Baruffaldi<br></div></div>