El Dilluns, 25 de març de 2013, a les 16:41:35, Adam Reichold va escriure: > 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.
All yours :-) https://bugs.freedesktop.org/show_bug.cgi?id=62735 Cheers, Albert > > 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 _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
