On Thursday, July 17, 2014 1:43:47 PM UTC+5:30, Saúl Ibarra Corretgé wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > >> I am still struggling with this. I plan to keep track of > >> .queued_bytes in write callback and when it is zero then only I > >> proceed with next uv_write. > > > > Why do you keep your own queued_bytes? The stream already does that > for you. > > >> Is it correct approach? I found two issues with this: > > > > Well, I don't think haveing some data queued is a bad thing. Just set > on some low and high watermaks: when more than "high" bytes are > pending, stop writing, when less than "low" bytes are pending, resume. > > >> 1. I just written 10 bytes to client. Despite client received > >> those bytes, .queued_bytes was still holding value 10 in callback > >> (resulting in not to call uv_write next time and forever) > > However, stream->write_queue_size was holding zero. > > > > I have no idea what .queued_bytes is. The libuv styream's > write_queue_size keeps the value until the callback is called, even if > data was sent a bit earlier, this is so that you can use it in the way > I described above. > > No I don't create my own variable. I was referring to req->queued_bytes which we get in uv_write_cb (I read in your first reply about both: stream's write_queue_size and queued_bytes in callback)
> >> 2. How much maximum value shall I allow to be hold by > >> .queued_bytes ? Is there any guideline for optimal performance ? > > > > I don't think there is a silver-bullet-value. If you put the > mechanisms inplace you can then do your own benchmarks. You could also > look into what values Node uses, as a reference. > > > Cheers, > > - -- > Saúl Ibarra Corretgé > bettercallsaghul.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTx4VMAAoJEEEOVVOum8BZyTUQAI5HTQR5yACr0ViTL22W+fVs > XVsm3kwbKIgnwTmKTtdpJa4Vb9KdPPGELsZ+oSan7g8lINqYQvI1QNDlecLcucEQ > iiDS9C3JH0n3wOmmEjR6a8AuexEqjPfpdTAC+Ftn7Xf9H7OQR7QBRdDWhW9FGiZo > XrtAlIHpNeEEhJwyFVmG4FfY4M7yiIlOFZqwIiylJvbIlpESZpnPEmQWKf2yFjEG > bkEfyGsXm66QWsAPhEw+ttNqoV6rid+q2DefVd7hkXj6g9MgkNxL7cYpXfyhmOx+ > 3oqGOQkkBQzQbbMh5eJOlnETAsk4ZturdNXwp9JXrnHCCfEwYpT889MBWeUA/Mt7 > Aso6GYZ4BgINKWrYcOAOzO0kDafoFUIbA6f/4yQoZL215MWhBBbi7VNmbbCk5VTC > IByTVzFiQtLBycPU1vzWMxMczo62qHZ4bQqtIL1mvjkRx52yTNMXREnJXC4zXJfs > 1uCyJ2uwV8AWkaNYlAyyzda36EwC9t7scEsxJIuITs6aJiwh8QwJnvPZr053ybSd > 8GwJWiaw5Bepoa+Nx6Q1wxj22/BKoOgMeCvpPMaE3Uf93MgMgl8uT5lyWh5XsSMk > iTXfLHo2mmssQe8YjHtYmht8mh2Xh+5rjIyoK94eeQonDAeIGCBlyyzkAO6lQWY+ > 9st26whTsbQtQYI2by3I > =06B1 > -----END PGP SIGNATURE----- > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
