From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tarantool-patches@freelists.org Subject: Re: [tarantool-patches] Re: [PATCH 03/11] sio: remove exceptions Date: Wed, 5 Dec 2018 11:42:41 +0300 [thread overview] Message-ID: <20181205084241.4oe53lf7cqhk7f66@esperanza> (raw) In-Reply-To: <e6c7f139-1619-acd1-2033-24b95a700166@tarantool.org> On Wed, Dec 05, 2018 at 12:29:10AM +0300, Vladislav Shpilevoy wrote: > > > > /** > > > * Receive a message on a socket. A wrapper for recvfrom(), but > > > - * throws exception on error except EAGAIN, EINTR, EWOULDBLOCK. > > > + * sets diagnostics on error except EAGAIN, EINTR, EWOULDBLOCK. > > > + * @param fd Socket to receive from. > > > + * @param buf Buffer to save message. > > > + * @param len Size of @a buf. > > > + * @param flags recvfrom() flags. > > > + * @param[out] src_addr Source address. > > > + * @param[in, out] addrlen Size of @a src_addr. > > > + * @param[out] is_error_fatal Set to true, if an error occured and > > > + * it was not EAGAIN, EINTR and EWOULDBLOCK. > > > + * > > > + * @param How many bytes are received, or -1 on error. > > > */ > > > ssize_t > > > sio_recvfrom(int fd, void *buf, size_t len, int flags, > > > - struct sockaddr *src_addr, socklen_t *addrlen); > > > + struct sockaddr *src_addr, socklen_t *addrlen, > > > + bool *is_error_fatal); > > > > This new API doesn't look good to me. Let's instead set diag and return > > -1 on every error and introduce a helper to check if a particular error > > code means that the socket would block (the name might need to be > > refined):> sio_wouldblock(errno) > > > > ? > > > > The only purpose of the out flag was to hide from a user details > of how exactly to check if an error is not critical: via errno, or > via checking diag_is_empty(diag_get()) or via any other way. So a > user wouldn't need to include errno or use complex constructions > like with diag. > > But as you wish. Lets find another way. > > Any names having 'wouldblock', 'block' or describing other concrete > behaviour can not be used. At least, sio_bind/listen can set EADDRINUSE, > which is not about blocking. > > Also, notion of 'critical' is different for various functions. I've > grouped errors in 4 groups: > > EINPROGRESS - sio_connect > > EADDRINUSE - sio_bind, sio_listen > > EAGAIN - sio_accept, sio_write, > EWOULDBLOCK sio_writev, sio_readn_ahead, > EINTR sio_sendto, sio_recvfrom > > ECONNRESET - sio_read > EAGAIN > EWOULDBLOCK > EINTR > > I can not implement one function for checking of any > error via errno because > > * EADDRINUSE is not critical for bind/listen, but > critical for connect; > > * EAGAIN, EINTR are not critical for IO, but critical > for connect; > > * ECONNRESET is not critical for sio_read, but critical > for sio_sendto. > > The list is not complete I think, and I do not want to fix some > crutches in a single error checking function each time when > something changed in any other sio function. OK, I see. I'll think what we can do about it. > > I can not use the simplest way !diag_is_empty(diag_get()) as well > because as I discovered, iproto thread does not clean diag in > some places after processing an error. For example, > iproto_connection_resume on error leaves an error in diag and > the error lives in the thread until next error. The same in > iproto_connection_on_input(), where catch() block does not > clears diag. > > I could use diag if I fixed these places, but I do not want > to rely on cleanness of external code. > > I decided to return from some functions a special code that > can be checked by sio_is_error_fatal(). > > See v2 thread for a new version of the commit. I do not paste > diff here, since in fact the patch is rewritten completely.
next prev parent reply other threads:[~2018-12-05 8:42 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-30 15:39 [PATCH 00/11] SWIM preparation Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 01/11] box: move info_handler interface into src/info Vladislav Shpilevoy 2018-12-03 11:05 ` Vladimir Davydov 2018-12-03 21:48 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-03 20:41 ` [tarantool-patches] " Konstantin Osipov 2018-12-03 21:48 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-04 8:52 ` Vladimir Davydov 2018-11-30 15:39 ` [PATCH 10/11] evio: remove exceptions Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 11/11] evio: turn into C Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 02/11] sio: remove unused functions, restyle code Vladislav Shpilevoy 2018-12-03 12:28 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-05 8:41 ` Vladimir Davydov 2018-11-30 15:39 ` [PATCH 03/11] sio: remove exceptions Vladislav Shpilevoy 2018-12-03 12:36 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-05 8:42 ` Vladimir Davydov [this message] 2018-11-30 15:39 ` [PATCH 04/11] sio: fix passing negative size_t to sio_add_to_iov Vladislav Shpilevoy 2018-12-03 13:50 ` Vladimir Davydov 2018-12-04 21:29 ` Vladislav Shpilevoy 2018-12-05 8:48 ` Vladimir Davydov 2018-11-30 15:39 ` [PATCH 05/11] sio: turn into C Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 06/11] evio: make on_accept be nothrow Vladislav Shpilevoy 2018-12-03 14:58 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-05 8:52 ` Vladimir Davydov 2018-11-30 15:39 ` [PATCH 07/11] coio: fix file descriptor leak on accept Vladislav Shpilevoy 2018-12-03 16:16 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 08/11] coio: fix double close of a file descriptor Vladislav Shpilevoy 2018-12-03 16:19 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-11-30 15:39 ` [PATCH 09/11] evio: refactoring Vladislav Shpilevoy 2018-12-03 16:37 ` Vladimir Davydov 2018-12-04 21:29 ` [tarantool-patches] " Vladislav Shpilevoy 2018-12-03 9:47 ` [PATCH 00/11] SWIM preparation Vladimir Davydov 2018-12-03 10:27 ` [tarantool-patches] " Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181205084241.4oe53lf7cqhk7f66@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [tarantool-patches] Re: [PATCH 03/11] sio: remove exceptions' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox