This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] basic_filebuf: 45628 + non-modal I/O
On Sep 23, 2010, at 2:48 PM, Paolo Carlini wrote:
> The last case was really special, because we had an open PR which couldn't be fully resolved without dealing with the seekoff issue at the same time.
Which case? Throwing from imbue?
> Now we have a pretty good improvement in, slightly risky, however, and in my opinion we should return for a while to normal mode, thus small, and more straightforward changes submitted first, possibly with additional testcases exercising the area which we are touching, even if we aren't really fixing bugs, but simply rewriting for cleanliness or performance, not correctness. Thus, if you can imagine anything falling under the latter chapter, I'm all eyes ;) I see that you are confident that your changes are all good,
On the contrary… there's still a lot of churn and uncertain issues in the latest in-progress set.
That's why I wanted feedback before going further.
> and for a reason, I agree that you know what you are doing and your idead are sound. I also see that you could save time by testing large chunks of work at once. But we don't know you well yet, you are touching pretty critical and old areas of the library about which we didn't receive much complaints so far, and, as maintainers, we must be careful. In due course, we can do a lot, but please bear with us, work in a relaxed way, as your spare time permits, and one week after the other everything will be reviewed, prioritized, committed immediately or in the worst case saved for when we break the ABI (at some point you may also get write rights and thus create and manage a branch for the latter, keep this in mind). This reasoning applies also to further improvements to <algorithm>, of course ;)
Fair nuff. The elimination of _M_reading/writing was something I anticipated to have a high
risk/reward ratio in the first place… maybe that affected my approach to it. Although the basic
change is mostly accomplished with a search+replace to substitute the function calls for data
members, the secondary changes had a surprising cascade effect. Caching always_noconv
alters the invariants of _M_codecvt. The semantics of _M_post_overflow are unsatisfactory
considering exceptions, so right now I'm working on changing it to _M_need_unshift. That is
also potentially cleaner, but upon trying to debug it, I got hit with a testcase failures, including
an imbue testcase! (Diagnosing that right now.)
As I said before embarking on this round, and again in the last message, there are other
things to do. There are a number of tangible benefits to having overflow preserve any
unwritten part of the put area, including the standard specifically requiring it. So I'll try to wrap
this up, post it to the list for posterity, and we can revisit this cluster later.