| delorie.com/archives/browse.cgi | search |
"Christopher Faylor" <cgf AT redhat DOT com> wrote: > There shouldn't really be that much overhead to the current method for > handling text/binary reads, though. It's just checking a bit field. At the coal-face it ends up being a bit more messy than that. For example, the fhandler::read code checks the readahead buffers for pending data but they will always be empty in binary-mode (AFAIK) . In fact there's a page of code before the check for whether a binary read is being done and only then does the code escape back to the caller. Since (AFAIK) you can't change the text/binary mode of an fd once it's been opened (and thus the readahead buffers always empty in binary-mode), that escape could come right at the top of the method. Perhaps. It might all be neater if a sysv streams-like approach were used: that is, write a fhandler that does text->binary conversion and vice-versa and "push" it on top of the raw (binary) fhandler if it's opened in binary mode. Then the base fhandler class wouldn't have any text-mode stuff in it at all. This sort of approach would then make it easier to override the read/write stuff in derived classes as they wouldn't have to care about text/binary mode at all. Another point I was pondering was whether the buffering done in the fhandler for text mode is Posix compliant. That is, it makes it possible for stuff to be written to a file and not be read by another process (or thread, whatever) even tho' the two processes perform some synchronization to make sure that the one reads after the other has written. It's probably not the world's most important issue tho'. My $0.02 // Conrad
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |