On Tue, May 4, 2021 at 12:51 AM Andreas Fritiofson < [email protected]> wrote:
> It feels entirely unnecessary to implement a buffering mechanism if the C > library already has a perfectly good implementation. > Agreed, but apparently it's not standard on Windows. I'm like a fish out of water in Windows development, but Googling suggests the problem is that windows sockets just have a different interface than file descriptors, so you can't use fread/fwrite/fflush on them. I think either live with the performance degradation*, or reimplement the > mentioned change to use socket calls only on windows, via a common wrapper > and some autotools magic. > It seems less painful to implement the buffering in OpenOCD, and that has the bonus that the performance improvement will work on Windows, too. I already did this for the writing, which gets you most of the performance back: 1 file changed, 33 insertions(+), 11 deletions(-) * the TCP socket should be buffering small writes as well, via the Nagle > algorithm. Is perhaps TCP_NODELAY set on the socket? > Not AFAICT from reading the source. In my case the socket is to a process on the same machine, so there may be some implicit flushing going on in the kernel for that kind of scenario. Tim >
