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