On 06/03/15 02:37, 贾凯 wrote:
The problem of libuv is that it does not call the completion callback right after write succeeds. Instead, it is only until all I/Os are performed that the callbacks are called. This means that if you have 1,000 connections sending 64KB of data, your code first allocates 64KB of memory 1000 times (64MB in total) and then call freefor all of those memory chunks, even when the network operation does not block. IMO, libuv should better call the completion callback immediately after the application returns the control back to the library after calling uv_write, so that the memory allocation pattern could be a repetition of malloc-and-then-free for 1000 times. (from http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html)
This is by design. You can see how plan to change it here: https://github.com/libuv/leps/pull/2 However we're still not going to fire the callbacks immediately, but will provide a way to let you know immediately when a socket is writable so you can write synchronously.
In the mean time you can use a uv_poll_t handle if you need total control of read and write operations.
Cheers, -- Saúl Ibarra Corretgé http://bettercallsaghul.com -- 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.
