Home > Enterprise >  BOOST Asio async_write_some vs asio::async_write , force a single write operation
BOOST Asio async_write_some vs asio::async_write , force a single write operation

Time:10-26

Some special files have semantics associated with individual writes. (For example, FunctionFS (USB gadgets in userspace) associates a single write to a sequence of USB packets within a single USB transfer. Two writes will never be merged into a single USB packet. Hence the first write may end with a short packet.)

I therefore don't want to use asio::async_write, because it allows zero or more calls to the underlying async_write_some of the passed stream. However if I use stream.async_write_some directly, it allows that not all the data will have been written.

What I need is the guarantee that the streams's async_write_some (of posix::basic_stream_descriptor) passes all buffers in the sequence to the vectored write system call, and write less data only when the system call decides to do so.

How can I achieve that? Am I on the completely wrong way?

CodePudding user response:

What would you use in terms of POSIX API? Likely it ends up the exact same underlying API that ASIO hooks into. So, if that API behaves in the way you describe you can expect ASIO to behave in the same way (not resulting in partial completions).

The only place where I readily know ASIO might have opinions on buffer division/operation is the other way around where SSL buffer-sequences may be combined prior to writes for performance reasons.

It would help if we knew both interfaces you're trying to contrast/impact analyze. E.g. there will be a difference between using asio::posix::stream_descriptor or asio::serial_port for obvious reasons. There might be platform differences at play, but I assume the platform is Linux because of FunctionFS.

  • Related