如何禁用 boost::iostreams 接收器中的缓冲区？
我使用 boost::iostreams 编写了一个“接收器”，这样当有人尝试写入 iostream 对象时，我基本上可以运行自己的代码。
不幸的是，系统中的某个地方有一个缓冲区，因此我的 Sink 的 write() 函数仅每隔 4kB 左右被调用一次。这是一个问题，因为我正在实现的接收器是固定大小（例如 128 字节），因此一旦写入这么多数据，就需要向调用者返回错误（类似于“磁盘已满”）
。调用者能够写入几千字节的数据并且不会返回任何错误，然后当刷新缓冲区时，额外的数据会默默地丢失，这给我带来了问题。
有谁知道是否可以以某种方式禁用此缓冲区？我已经尝试了这里针对通用 iostreams（例如 pubsetbuf）的许多建议，但它们似乎都不适用于 Boost 实现。
问题代码是我正在开发的库的一部分，如果有帮助的话，可以从 GitHub 获取（运行“make check”，您将看到由于此问题而导致的一次失败。）
任何建议将不胜感激！
I've written a 'sink' using boost::iostreams, so that I can essentially have my own code run when someone tries to write to an iostream object.
Unfortunately there is a buffer somewhere in the system, so that my Sink's write() function only gets called every 4kB or so. This is a problem because the sink I am implementing is a fixed size (e.g. 128 bytes) so once this much data has been written it needs to return an error to the caller (something like 'disk full'.)
Because of the buffer the caller is able to write a few kilobytes of data and no errors are returned, then later when the buffer is flushed the extra data is silently lost, which is causing me problems.
Does anyone know if it's possible to somehow disable this buffer? I've tried many of the suggestions here for generic iostreams (e.g. pubsetbuf) but none of them seem to apply to the Boost implementation.
The problem code is part of a library I am working on, which is available from GitHub if it helps (run 'make check' and you will see one failure because of this problem.)
Any suggestions would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我已经找到了解决方法。您必须手动决定何时要执行刷新，但如果您进行查找 - 即使查找到相同的位置，即
stream.seekp(0, std::ios::cur)-那么它将导致所有内容都按预期被刷新。这是一个有点可怕的解决方法，但它似乎在大多数情况下都可以完成工作。
I think I've found a workaround. You have to manually decide when you want to perform a flush, but if you do a seek - even seeking to the same position, i.e.
stream.seekp(0, std::ios::cur)- then it will cause everything to be flushed as expected.It's a bit of a horrible workaround but it seems to do the job most of the time.