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. 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
