Hi over the last days I've been testing Tracker 0.16.2 with a large set of real world test data which are mostly PDFs from various sources. From the start I ran into an issue that tracker-extract repeatedly got stuck in one PDF or another.
Looking at the Tracker debug logs, process stack back-traces and other debug data, it seemed the tracker-extract parent and child processes where somewhere deadlocked sending data from the child to the parent via the pipe IPC fd. Um... parent (with a glib mainloop), child, glib, fork() ? <https://developer.gnome.org/glib/2.37/glib-The-Main-Event-Loop.html> "On Unix, the GLib mainloop is incompatible with fork(). Any program using the mainloop must either exec() or exit() from the child without returning to the mainloop." As I'm only really at the beginning of an in depth analysis, I can't say for sure that the hangs I see are the cause of this, but knowing there seems to exist a fundamental design flaw in tracker-extra-pdf, I'm asking for thoughts on this. Afaict, the right design would involve an exec() in the child and using some other IPC channel. I'll happily volunteer. Thoughts? -r -- Ralph Böhme <r...@netafp.com> Netatalk Developer | Support | Services Curslacker Deich 254, 21039 Hamburg, Germany http://www.netafp.com/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
