Ben, I like your approach. That was, what I initially wanted to do.
Also, I'm +1 on removing uv_read2_cb. Saghul, Are you ok with both removing read2_cb and adding two functions for count and types of pending handles? On Thu, Jan 9, 2014 at 5:30 PM, Saúl Ibarra Corretgé <[email protected]> wrote: > On 01/09/2014 01:18 PM, Ben Noordhuis wrote: >> >> On Wed, Jan 8, 2014 at 10:33 PM, Fedor Indutny <[email protected]> wrote: >>> >>> Hey people! >>> >>> I'm currently trying to work around problem with receiving fds over >>> IPC pipe on SmartOS. The thing is that SmartOS may concatenate >>> multiple fds and emit them at once in a single SCM_RIGHTS message. >>> >>> I decided to queue them up on a stream instance, but notifying users >>> about pending fds requires an API change. Initially, I thought about >>> passing NULL-buffer as a `read2_cb` with zero `nread`, when there's >>> pending fd (see: >>> >>> https://github.com/joyent/libuv/pull/1056/files#diff-56343bd7ad8bf449c2693082fb3e4081R379 >>> ). But we are afraid that many users are not prepared for such >>> circumstances, and, considering that this situation is quite rare and >>> platform-specific, users may not ever observe it, when developing >>> their apps. >>> >>> Thus, I want to collect some feedback from you, people! Please let me >>> know if it'll break existing code for you, or if you have any better >>> ideas for this! >>> > > This does break my current code on pyuv, since I assume the buffer won't be > NULL in case nread >= 0. But more importantly, until now alloc_cb and > read_cb came in pairs, which wouldn't be the case anymore and someone may > rely on it. FWIW I was going to, but ended up not doing it. > > > >> Here is a suggestion: make it explicit in the API. How about changing >> the prototype of uv_read2_cb from: >> >> void (*)(uv_pipe_t* pipe, ssize_t nread, const uv_buf_t* buf, >> uv_handle_type type); >> >> To something like: >> >> void (*)(uv_pipe_t* pipe, ssize_t nread, const uv_buf_t* buf, >> unsigned npending); >> >> And then have the user execute the following code: >> >> for (i = 0; i < npending; i++) { >> uv_handle_type type = uv_pipe_pending_handle_type(pipe); >> if (type == UV_TCP) { >> uv_tcp_t* tcp_handle = /* ... */; >> uv_tcp_init(pipe->loop, tcp_handle); >> uv_accept((uv_stream_t*) pipe, tcp_handle); >> } else if (type == UV_PIPE) { >> // etc. >> } >> } >> >> Maybe shuffle the uv_read2_cb parameters around so that code still >> using the old function prototype will fail to build. Not everyone >> compiles with -Wall -Wextra or pays attention to the warnings it >> generates. >> >> You could even drop the uv_read2_cb prototype altogether, replace it >> with uv_read_cb and have the user call uv_pipe_pending_handles_count() >> from his callback. >> > > Hey Ben! You mean just calling the read_cb once and having the user consume > all pending descritors? That sounds good to me! > > > Cheers, > > -- > Saúl Ibarra Corretgé > 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/groups/opt_out. -- 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/groups/opt_out.
