This won't allow us to pass multiple uv_buf_t :( But yeah, requestify all the things!
On Mon, Jun 30, 2014 at 6:30 PM, Saúl Ibarra Corretgé <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/30/2014 04:13 PM, [email protected] wrote: > > I am 100% in favor of switching to asynchronous read instead of > > read_start. However I think you want to stick with alloc_cb unless > > you can think of something better. > > > > Imagine you have 10k open tcp connections that all *may* receive > > data. Then you are pre-allocating 64k * 10k = 640mb of buffers > > alone, which are almost never used. With alloc_cb, libuv can ask > > the embedder to allocate memory as late as possible. For TCP > > handles buffers can be allocated very much "last minute", while for > > operations that happen in the thread pool the buffer can be > > allocated upfront. > > > > Ah, you are so right! I proposed this update on another email: > > UV_EXTERN int uv_read(uv_read_t* req, > uv_stream_t* handle, > uv_alloc_cb alloc_cb, > uv_read_cb read_cb); > > This would actually make it more flexible, I think: those who want to > allocate it upfront can embed the req in another structure and attach > their preallocated buffers there and then use them in alloc_cb. > > PS: I need to give this 2nd version a bit more thought, I wrote it > while multitasking so I might be missing something. > > - -- > Saúl Ibarra Corretgé > bettercallsaghul.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTsXRvAAoJEEEOVVOum8BZf/oQALkyiicsZREXSXuehVTQ/gTk > QGT0bE3DZ407P3+KVyC66KR2rqY6k4yC0ScMeeP+zMbZRFEnz+O3k6ZnE7FAUnzk > eCGrGq5LNN+K+yq1oiXeQDh4eJiXNdQHHa0lNEXLdZ/nUpYOXfcB1om4TYfHm7kB > 9kKGQOHwn2FMSSEr/uRXv0m31DTWNHYhbvyxciVzZ51ewRm7IHB3XXBpjMDYgj7U > NcJIwWLNZPyXPqzInXu6837wbUojmA9iMHuCSwLIsbVIsYeajgaPvG6H7O3yItSQ > mMWPzXRx1gnX44476yZgwNte7UE+lD4qfsGHEK/KcIzKW7ysV2uHs/cguzCAdo79 > qRW8noOFZJryK7+Z9Fv9FqV52FmprKFkpVVQ3RdN/Qka+mg0MRqHECOtoQ9OlNMt > P2XSp5Z8rXeZVc/0KaoxWuqF4cWnNvbTGQdZ7ex8fg+CbN2bI4Zu4UEPWBuh/eDn > fDMuE3jTCtRtoXAW5cu/NxjxupJgELhsQIK/uvJE5oRnVHINgrSInuK9gJVoOgtF > 86U2pMbXSYOWYhLe9B4L4PA2871pW+XnFxcro+lVBYPVwlzV33lL3h/eDXR29dVq > rrOc4QDtvxAEytvAfFndloEXPB7lwkBvhB3nD12amO0bieAOnCdLdw9VR4Q8oud/ > kdFMogn/pe2cc2gIJrXG > =C+8A > -----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. > -- 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.
