Hello, Am 25.03.2013 08:44, schrieb Thomas Freitag: > Am 25.03.2013 00:51, schrieb Albert Astals Cid: >> El Diumenge, 24 de març de 2013, a les 16:31:05, Adam Reichold va >> escriure: >>> Hello, >>> >>> Am 24.03.2013 06:32, schrieb Thomas Freitag: >>>> Am 23.03.2013 20:08, schrieb Albert Astals Cid: >>>>> El Dissabte, 23 de març de 2013, a les 20:01:58, Thomas Freitag va >>>>> >>>>> escriure: >>>>>> Am 23.03.2013 18:59, schrieb Ihar `Philips` Filipau: >>>>>>> On 3/23/13, Ihar `Philips` Filipau <[email protected]> wrote: >>>>>>>>> (i tried to find a way to duplicate a FILE* but failed) >>>>>>>> How did you duplicate FILE*? >>>>>>>> >>>>>>>> How did the `fdopen( fileno(oldfile), mode )` failed? >>>>>>> Nope. This is the right way: >>>>>>> >>>>>>> int new_fd = dup( fileno(oldfile) ); >>>>>>> FILE *new_file = fdopen( new_fd, mode ); >>>>>> Duplicating the FILE pointer in that way is not a solution: I >>>>>> tried it >>>>>> that way when I began to implement thread safe feature: At least >>>>>> under >>>>>> Ubuntu and gcc the duplicated file pointer uses the same underlying >>>>>> buffer, and that corrupts the thread safe feature. >>>>> Exactly, it is the documented behaviour >>>>> >>>>> "They refer to the same open file description and thus share file >>>>> offset" >>>>> >>>>>> That's why I used the >>>>>> fileName to create a complete new file pointer. >>>>>> Of course we can do it in that way if we detect that the file is >>>>>> deleted >>>>>> (and only then!), but a program which use threads to render different >>>>>> pages the same time will then render garbage :-( >>>>> No. We either write the file back to a temporary location as i >>>>> suggested in my >>>>> initial mail, or use the only fd with locking. I think i'm favoring >>>>> the second >>>>> use case since writing the file back might not even work if we run out >>>>> of free >>>>> space. >>>> I think, You're second solution is quite easy to implement (I mean >>>> really only easy to implement, it will take some time to change every >>>> code snippet and deeply test the changed code): since FileStream >>>> already >>>> use it's own buffer, there is no really need of the underlying system >>>> file buffer. So implementing something like a sharable GooFile (or >>>> extend gfile) which can be locked and remember the next read >>>> position in >>>> FileStream and then do something like gfile->read(readposition, buf, >>>> buflength) wouldn't really reduce the speed. But then I would prefer >>>> use >>>> the low level file handles instead of the file pointer. And it's even >>>> better than to write platform specific code and rely on Windows that >>>> the >>>> open file is not deletable and search for a Mac solution. >>>> Then the UniqueFileStream mechanism and the streamOwner instance >>>> variable can be removed, too. >>>> On the other hand: who deletes a just opened file and expects stability >>>> of the application which just opens the file? Is it really worth the >>>> effort? >>> Seems I am a bit to the party, but for what it's worth: I asked myself >>> the same question as Thomas. Providing a file object that takes care of >>> looking and per-thread offset seems like the best solution (ideally >>> implementing using low-level I/O), but is it really that useful to be >>> able to continue rendering unlinked files as long as Poppler fails >>> gracefully, i.e. does not crash. >> We still have the file open, it should work. > Ok, ok, I surrender. If You just post it to find a mug who will do it, > then open a bug report and assign it to me :-) Even if I don't feel like > to open an issue again which I just closed after working on it round > about 9 months, it is easier to make the mistakes by my own instead of > searching errors from others :-) > But I'm too busy in the moment with other projects to do it immediately, > so it will take probably a while. > > Cheers, > Thomas
I would like to help implementing and testing this. Preferably under the advisement of Thomas. If he feels like that would actually help, that is. Regards, Adam. >> >> Cheers, >> Albert >> >>> Best regards, Adam. >>> >>>> Cheers, >>>> Thomas >>>> >>>>> Cheers, >>>>> >>>>> Albert >>>>>> Cheers, >>>>>> Thomas >>>>>> >>>>>>> It is OK to use *NIX function here - the dup() - since deleting open >>>>>>> file can happen only on the *NIX-like OS, Mac OS X included. Windows >>>>>>> doesn't allow that. Correct me if I'm wrong. Tested on Linux, HP-UX >>>>>>> and Solaris for the safety sake: the fclose() would close the >>>>>>> dup()ed >>>>>>> file descriptor. >>>>>>> >>>>>>> Though I'm not sure how to integrate that with the rest of the >>>>>>> portable >>>>>>> code. :) >>>>>>> >>>>>>> FYI. >>>>>>> _______________________________________________ >>>>>>> poppler mailing list >>>>>>> [email protected] >>>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler >>>>>>> >>>>>>> . >>>>>> _______________________________________________ >>>>>> poppler mailing list >>>>>> [email protected] >>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler >>>>> _______________________________________________ >>>>> poppler mailing list >>>>> [email protected] >>>>> http://lists.freedesktop.org/mailman/listinfo/poppler >>>>> >>>>> . >>>> _______________________________________________ >>>> poppler mailing list >>>> [email protected] >>>> http://lists.freedesktop.org/mailman/listinfo/poppler >>> _______________________________________________ >>> poppler mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/poppler >> _______________________________________________ >> poppler mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/poppler >> >> . >> > > > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
