3 ms·

You actually can observe the same behavior in most async APIs which follow a "pull model". E.g. if you do "await socket.ReadAsync(buffer...)" in C# you would al

You actually can observe the same behavior in most async APIs which follow a "pull model". E.g. if you do "await socket.ReadAsync(buffer...)" in C# you would also need to have preallocated the buffer and keep it alive for the whole duration of the async operation. Same is true for C++ boost asio async reads. Even if you use the pure C WinAPI IOCP methods you have to preallocate the buffers. The readyness model avoids this, as described in the article. But it will also lead to a more event driven programming model. I think the preallocation might be a problem if the use case is a server that holds an enormous amounts of mostly inactive connections (e.g. websocket server). For most servers I don't see a problem with it. This method also has a benefit for performance: You often can totally avoid dynamic memory allocation during runtime with this model. You allocate the receive buffer once for the connection and then reuse it for the whole lifetime. In the push model you either need to allocate a fresh buffer for the new data or retrieve one from a pool, which is still more expensive.

porpoisemonkey 10y ago
> This method also has a benefit for performance: You often can totally avoid dynamic memory allocation during runtime with this model. You allocate the receive buffer once for the connection and then reuse it for the whole lifetime. There is a security concern here; you'd better be sure to flush the buffers correctly or you could cause memory to leak between sessions. If I were writing a server to handle a sensitive task such as executing payment transactions I'd probably take the less memory efficient approach of allocating a new buffer for every connection to lower the risk of data spilling between connections.
- gpderetta 10y ago
  allocating a new buffer doesn't give any guarantee as you might be given back a just dealocated buffer by the allocator with its original content mostly intact. You need to explicitly scrub any sensitive data yourself before deallocating. At that point you might just reuse the buffer yourself.

porpoisemonkey 10y ago

> This method also has a benefit for performance: You often can totally avoid dynamic memory allocation during runtime with this model. You allocate the receive buffer once for the connection and then reuse it for the whole lifetime. There is a security concern here; you'd better be sure to flush the buffers correctly or you could cause memory to leak between sessions. If I were writing a server to handle a sensitive task such as executing payment transactions I'd probably take the less memory efficient approach of allocating a new buffer for every connection to lower the risk of data spilling between connections.

gpderetta 10y ago
allocating a new buffer doesn't give any guarantee as you might be given back a just dealocated buffer by the allocator with its original content mostly intact. You need to explicitly scrub any sensitive data yourself before deallocating. At that point you might just reuse the buffer yourself.