This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] basic_filebuf: 45628 + non-modal I/O

On Sep 22, 2010, at 11:36 PM, Paolo Carlini wrote:

> Just to clarify: luckily, we don't provide this kind of 'ABI' guarantee. And, well I suppose you already know that, because we don't want to waste time committing and reverting the same patch in 24 hours ;) More seriously, about your idea of not using _M_reading and _M_writing entirely, I'm in general in favor - with the usual caveats about performance, etc, we don't want to call virtuals when we could have avoided it, and so on. Note, of course that, for the time being, we cannot really *remove* the data members, because that changes layout and size of the basic_filebuf class and severely breaks the ABI. If therefore it would be convenient or not to do anyway the change right now I don't know.

Here's my current work in progress. Eliminating the _M_reading/writing and caching always_noconv are both pretty major changes.

The noconv optimization had a surprising side effect in that the previous methodology, the expression __check_facet(_M_codecvt).always_noconv(), implemented a special case where _M_codecvt was allowed to be NULL. It is a messy problem: if it's NULL, then the very next I/O operation will throw a bad_cast. The only problem solved is that imbue tolerates a locale without a codecvt. (I don't mean a trivial one, I mean NONE.) Instead of throwing anything, it enters an invalid state so the very next operation throws. Meanwhile there's a performance hit from checking for that state in every function. Yuck.

The new semantics are that the installed locale must have a codecvt while the file is open. This allows for creation of a filebuf while the current locale is missing one, or even to imbue such a defective locale, as long as !is_open(). Attempting to open with no codecvt returns false. Attempting to imbue an open file without a replacement codecvt throws a bad_cast.

Also, imbue was replicating code from _M_get_ext_pos, and had some wrongheaded stuff, so I completely rewrote it.

One thing I'm still thinking about is whether _M_post_overflow = true/false should be guarded by a catch(...) block.

Feedback is appreciated! Also, please run this through the performance suite. (I still can't run it, possibly because of Darwin.) It fails the razor's-edge sync test, but that is a separate issue for later.

Attachment: filebuf_state_noconv.patch
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]