00:29:25  * Guest72457changed nick to indutny
01:02:49  * cm_joined
01:03:45  <cm_>Hi. Is it a good place to ask technical questions about libuv?
01:07:08  <cm_>it seems that internal new_socket() function can return positive error code -- it seems like a bug, but I'd like to confirm it before submitting it to issues list
01:12:43  <indutny>hi
01:12:50  <indutny>this is a good place, indeed
01:13:35  <indutny>can it, though?
01:40:58  * AtumTquit (Remote host closed the connection)
01:49:28  * qardquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:17:31  * qardjoined
05:05:50  * qardquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:51:12  * qardjoined
07:55:58  * qardquit (Quit: qard)
09:49:47  * paolofquit (Ping timeout: 276 seconds)
09:49:48  * paolof_joined
11:08:04  * abhishekjoined
11:11:11  <abhishek>Hi, trying to debug one case where uv_write isn't invoking uv_write_cb callback - running on libuv v1.13.1 debian9
11:12:33  <abhishek>any suggestion(s) to debug it? Weird thing is this only seems to happen under load i.e. works fine when app does 1K or so uv_write call/s but with 10K such calls triggering of uv_write_cb stalls
11:17:00  * AtumTjoined
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:47  * mylesborinsjoined
12:13:45  <sgimeno>abhishek, that version is quite old, you could update to the latest 1.19.1
12:14:29  <sgimeno>abhishek, can you reproduce the issue when running the program with strace? that can help trying to figure out what's going on
12:16:05  * abhishekquit (Ping timeout: 240 seconds)
15:36:34  * Fishrock123joined
15:59:11  * qardjoined
16:08:08  * qard_joined
16:30:07  * abhishek1joined
16:59:15  * abhishek1quit (Quit: Leaving.)
17:10:55  * abhishek1joined
17:18:06  * qard_quit (Quit: qard_)
17:38:53  * abhishek1quit (Quit: Leaving.)
18:10:55  <cm_>indutny: yes, lines 55 and 61 (in src/unix/tcp.c) can return positive error codes that may bubble up to client
18:11:59  <indutny>cm_: which version are you referring too?
18:15:21  <cm_>huh... am I looking at the wrong branch (v1.x)? (https://github.com/libuv/libuv/blob/v1.x/src/unix/tcp.c)
18:16:41  <cm_>I switched to 1.19.1 tag and tcp.c content is the same
18:24:17  <cm_>indutny: v1.19.1
18:25:12  <indutny>cm_: `getsockname` returns non-positive value
18:25:14  <indutny>that's by spec
18:25:29  <indutny>same for `bind`
18:25:39  * Fishrock123quit (Remote host closed the connection)
18:25:52  <indutny>they both practically return either 0 or -1
18:26:00  <indutny>I'd bet that it is part of POSIX standard
18:27:11  <cm_>my bad... I didn't read man page carefully enough, thought ERRORS section is for return value
18:28:42  <cm_>but this also means that original error code will be lost -- is it ok? (that was my question #2 -- I noticed the loss of error code in places like event loop creation, etc)
18:31:52  <cm_>some background: I am trying to "wrap" libuv to be used with libcoro in C++ code and trying to figure out how error handling will look like. Having generic "libuv error" isn't ideal
18:32:06  * Fishrock123joined
18:40:56  <cm_>question #3: if uv_listen() callback doesn't call uv_accept() (for example because there is no memory to allocate uv_tcp_t) -- will it be triggered again ad infinitum? Is there a way to discard currently pending connection from the backlog without doing memory allocation?
18:40:57  <indutny>cm_: original return value is either 0 on success
18:40:59  <indutny>or -1 on error
18:41:25  <indutny>I don't think it will
18:41:30  <indutny>also, I missed question #2 :D
18:42:41  <cm_>indutny: question #2: I noticed the loss of error code in places like event loop creation -- is it ok?
18:43:45  <indutny>cm_: examples?
18:43:50  <cm_>indutny: question #1: in the rest of tcp.c we always return (-errno) on error. why new_socket() is special?
18:45:12  <cm_>indutny: q#2: uv_default_loop() returns NULL on error -- original error is lost.
18:46:00  <indutny>q#2: historical reasons
18:46:04  <indutny>you can always use `uv_loop_init`
18:46:09  <indutny>and handle the errors manually
18:46:51  <cm_>well, it isn't about handling them -- it is about getting them, wrapping them and presenting them to user. But I see your point
18:48:35  <cm_>about q#3 -- are you sure? I thought connection stays in backlog until accept() -- i.e. in next loop iteration it should detect that connection is pending and invoke callback again
18:52:26  <cm_>indutny: I need to step out for 1 hour. If you have anything to say -- please do. Thank you for your help (past and future) :)
18:54:25  <indutny>cm_: you can always test it :)
20:00:31  * awakecodingquit (Remote host closed the connection)
20:00:50  <cm_>indutny: well, I am kind of sure it will go bananas, so I was leading into "is there a way to discard pending connection in a no-fail manner". But I'll surely test it in any case
20:03:33  <indutny>` /* The user hasn't yet accepted called uv_accept() */`
20:03:41  <indutny>there is such comment in unix/stream.c
20:03:48  <indutny>also, I wrote some parts of that code
20:04:12  <indutny>I'd appreciate if you could quantify "kind of sure" with documentation or source code reference next time ;)
20:04:26  <indutny>or your test case
20:29:46  <cm_>indutny: sigh... hard to quantify this without spending long time digging in the code -- that is why I am asking questions here :). In any case -- I see in unix/stream.c that in this case (accepted_fd != -1) we stop watching for POLLIN events -- i.e. there will be no endless spinning. But does it mean we are going to get stuck? (since we aren't going to get any "new connection pending" events)
20:30:36  * joocain2_joined
20:33:31  <indutny>you'll get one event for pending connection
20:33:36  <cm_>indutny: Is there a way to recover from this situation if I can't call uv_accept() due to malloc failure? I see only two ways to reset 'accepted_fd': uv_close() or uv_accept().
20:33:41  <indutny>Just to clarify my earlier comment
20:33:54  <indutny>I wasn't expressing frustration over receiving questions
20:34:11  <indutny>It was rather over not taking answers seriously
20:34:33  <cm_>that is ok -- after that snafu with man, you could call me anything you want :)
20:35:20  * joocain2quit (Ping timeout: 255 seconds)
20:36:08  <indutny>you can have a spare uv_tcp_t object allocated ahead of time, just in case
20:36:18  <indutny>uv_accept into it and close it
20:36:46  <cm_>huh... this should work
20:39:44  <cm_>in fact, I think I saw similar discussion in libev mailing list. I spent last 2 weeks reading everything I could find on async programming, event loops and coroutines. Trying to connect everything together and imagine what api to present to end-user. Total brain overload...
20:39:59  <cm_>Thanks for help
20:42:13  <cm_>wait a second... I thought you can't use handle until after uv_close() callback is invoked. Which means I wouldn't be able to handle two simultaneously pending connections. Am I?
20:42:26  <cm_>*reuse
20:43:45  <indutny>You could call read_stop on a server
20:43:53  <indutny>To prevent further connections from popping up
20:44:02  <indutny>Although, this won't help in IPC case
20:45:35  <indutny>yeah, there's probably no way to do it
20:45:41  <indutny>to handle it gracefully
20:45:46  <indutny>feel free to open an issue on our tracker
20:45:59  <cm_>maybe it makes sense to be able to pass NULL into uv_accept() with associated "just discard it" semantics?
20:46:11  <cm_>(NULL for cb)
20:46:44  <cm_>ok, I'll open a case
20:51:18  <cm_>indutny: q#4 -- on x64 box 'make install' puts libraries into /usr/local/lib (instead of /usr/local/lib64, as I would expect). It can be addressed with ./configure --libdir=/usr/local/lib64, but then you get a warning from libtool during install. Is it supposed to work this way?
20:52:30  <cm_>I noticed that many libs have the same behavior -- is it a convention of some sort? or /usr/local/lib64 is not a right place?
20:58:38  <indutny>I'm afraid this is not something that I'm expert in
20:58:53  <indutny>Isn't it an autotools stuff?
21:03:17  <cm_>I guess... I am very vaguely familiar with autotools
21:23:17  * qard_joined
22:45:23  * qard_quit (Quit: qard_)
22:57:49  * qardquit (Quit: Textual IRC Client: www.textualapp.com)
23:06:07  * qardjoined
23:49:21  * Fishrock123quit (Quit: Leaving...)