00:00:08  * fourqchanged nick to fourq|away
00:59:34  * fourq|awaychanged nick to fourq
01:32:53  * alexforsterjoined
01:35:34  * alexforsterquit (Client Quit)
02:13:53  * brsonquit (Quit: leaving)
02:21:17  * evanluca_joined
02:21:33  * evanlucasquit (Read error: Connection reset by peer)
02:29:20  * tunniclm_quit (Ping timeout: 260 seconds)
03:04:55  * bwoebiquit (Ping timeout: 240 seconds)
05:19:23  * evanluca_quit (Read error: Connection reset by peer)
05:19:41  * evanlucasjoined
05:31:06  * Left_Turnquit (Ping timeout: 240 seconds)
06:43:09  * seishunjoined
06:44:23  <txdv>iamtakingiteasy: the reason why most of the stuff is not on the stack is
06:44:28  <txdv>the lib is asynchronous
06:44:31  <txdv>its not blocking
06:44:38  <txdv>functions tend to run through and the stack get cleared
06:44:59  <txdv>you could use the stack for the loop if you block with uv_run
06:58:01  * mmickojoined
07:01:26  <iamtakingiteasy>txdv: thank you. Though it still seems to me as completly unnesessary, if not to say confusing, in case of simple examples; not supposed to have any initializations beyond main() function, yet still doing full run-time memory allocation and de-allocation for constantly-sized data structure with no complicated life-cycle.
07:05:33  <txdv>well, if you look at the tests, most of them are not dynamically allocated
07:06:38  <txdv>the problem is the same
07:06:44  <txdv>https://github.com/libuv/libuv/blob/v1.x/test/test-udp-try-send.c#L42-L47
07:06:49  <txdv>either you allocate them like this
07:07:02  <txdv>which means you are a predefined size and you can't get above it
07:07:13  <txdv>or you do it dynamicallty
07:07:41  <txdv>becauase if you do it on the stack, no function blocks, every libuv is supposed to finish immediately
07:08:08  <iamtakingiteasy>speaking of size, how can you get above it in case when malloc argument is a compile-time sizeof() construct (every case i've seen)?
07:08:12  <txdv>so if you do create a new socket and connect somewhere, you handle the connection even in the callback
07:08:42  <txdv>i dont understand the question
07:09:39  <iamtakingiteasy>i am refering to >txdv which means you are a predefined size and you can't get above it< -- you have the same pre-defined size at compile-time both with malloc and stack allocation
07:10:40  <txdv>well the sizes of the structs are predefined
07:10:49  <txdv>however, if you create a an array with malloc
07:10:53  <txdv>you are free to make it as big as you want
07:11:30  <txdv>malloc is a dynamic allocation, you can have as many dynamic allocations as you want
07:13:01  <txdv>if a connection comes in, you can use malloc to allocate some memory for the tcp struct for example
07:13:13  <txdv>and on disconnect you free that
07:13:34  <txdv>if you use static program allocation, you will have a predefined size
07:13:49  <txdv>its either an element or an array, but its static and will never grow
07:14:19  <txdv>if you try to put it on the stack, the functions run through immediately, once it is out of scope, the allocated stack memory is void
07:15:27  <txdv>you see in my test, i know exactly how many sockets i will need
07:15:30  <txdv>so i create 2 of them
07:18:04  <txdv>iamtakingiteasy: i hope you understood what i wanted to say
07:18:25  <txdv>to summarize: libuv doesn't block, all the structs allocated on the stack in the function are void past the actual event
07:19:11  <txdv>so if you have a connect and disconnect event, you link a function to the connect event, you allocate some structs on the stack in that function
07:19:29  <txdv>but all of them are void after the function is done handling the event
07:19:47  <txdv>and you cant use blocking calls in that function because it will stop the entire event loop
07:21:23  <txdv>and if you use that allocated struct in the disconnect event, you have left the connect event function and thus the pointer to the stack probably contains garbage
07:30:01  * Left_Turnjoined
07:33:47  <Ralith>iamtakingiteasy: I pretty much always place my uv_loop_t on the stack, and generally most of the other stuff is directly inside something or other as well
07:34:09  <Ralith>one of the nice things about libuv is that it lets you do that, vs other libs that always unavoidably allocate everything behind the scenes
07:36:17  <daurnimator>for a uv_loop_t I can't imagine it matters much
07:36:43  <daurnimator>it's a pretty much unheard of use-case to create/destroy them on a hot path
07:37:19  <daurnimator>makes more sense to be consistent with allocations than to prematurely optimize
07:56:34  * seishunquit (Ping timeout: 240 seconds)
08:00:15  <txdv>since uv_run is the only blocking function, you can place it in the same function
08:00:23  <txdv>or block
08:04:07  <txdv>daurnimator: here is a scenario, you are embedding the libuv somewhere else
08:24:20  * Ruyi-HomePCjoined
08:24:28  * Ruyi-HomePCquit (Client Quit)
08:24:45  * evanlucasquit (Read error: Connection reset by peer)
08:24:55  * evanluca_joined
08:51:51  * zju1joined
08:53:10  * zju3quit (Ping timeout: 260 seconds)
09:14:56  * rendarjoined
10:18:07  * Nackjoined
10:20:53  * nmdguerreirojoined
10:21:26  * Nackpart ("Leaving")
11:44:13  <nmdguerreiro>hi - I'm doing some work on an open-source HTTP server library based on libuv (https://github.com/haywire/haywire). I'm finding that when I open a large number of connections using wrk (around 5k in my case), I don't get nread = UV_EOF not UV_ECONNRESET for all the connections that are closed and after running wrk (a load testing tool), I still see a number
11:44:13  <nmdguerreiro>of connections marked as ESTABLISHED using netstat (and none on the remote host, btw). I know it's a vague question, but how can I detect that the peer has disconnected? Wouldn't the read callback always be called with nread < 0 ?
12:15:47  <nmdguerreiro>digging further, it seems like the FIN packets are never being received (maybe due to packet loss)
12:17:25  <nmdguerreiro>I guess that's something we should handle, by implementing some sort of reaper that kills inactive connections
12:32:36  * mmicko_joined
12:35:32  * mmickoquit (Ping timeout: 256 seconds)
12:47:05  <saghul>nmdguerreiro: yep, checking for nread < 0 is the way to go
12:47:40  <saghul>you want to have a timer anyway, in order to prevent the slowloris attach, I assume
13:05:09  * matrixis1changed nick to matrixise
13:21:43  * nomagicjoined
13:22:44  * nomagicquit (Client Quit)
13:27:22  * mmickojoined
13:30:11  * mmicko_quit (Ping timeout: 264 seconds)
13:34:07  * fourqchanged nick to fourq|away
13:34:14  * fourq|awaychanged nick to fourq
13:34:37  * alexforsterjoined
13:45:41  <nmdguerreiro>Thanks @saghul
13:55:09  * zju3joined
13:55:48  * zjuquit (Ping timeout: 248 seconds)
13:55:58  * zjujoined
13:57:08  * zju1quit (Ping timeout: 256 seconds)
14:15:24  * bradleymeckjoined
15:46:53  * bradleymeckquit (Read error: Connection reset by peer)
16:03:11  * Damn3dquit (Ping timeout: 264 seconds)
16:03:34  * Fishrock123joined
16:07:24  * Damn3djoined
16:21:19  * tunniclm_joined
16:31:24  * rmgjoined
16:33:12  * tunniclm_quit (Ping timeout: 250 seconds)
17:06:15  * seishunjoined
17:22:12  * Left_Turnquit (Ping timeout: 248 seconds)
17:31:56  * dap_joined
18:04:15  * davijoined
18:15:42  * brsonjoined
19:01:23  * evanluca_changed nick to evanlucas
19:18:22  * Fishrock123changed nick to Fishrock|away
19:18:41  * Left_Turnjoined
19:21:43  * Fishrock|awayquit (Remote host closed the connection)
19:25:44  * tunniclm_joined
20:22:37  * Fishrock|awayjoined
20:27:41  * Fishrock|awayquit (Ping timeout: 276 seconds)
21:14:52  * alexforsterquit (Quit: Textual IRC Client: www.textualapp.com)
21:15:41  * Fishrock|awayjoined
21:17:54  * rendarquit (Ping timeout: 252 seconds)
21:23:56  * rendarjoined
21:35:26  * daviquit (Ping timeout: 272 seconds)
21:40:30  * zju3quit (Ping timeout: 245 seconds)
22:06:33  <daurnimator>txdv: if you're embedding libuv somewhere else, you'll be using no_wait, and hence probably want to be allocating your uv_loop_t on the heap
22:07:26  * seishunquit (Ping timeout: 240 seconds)
22:49:46  * brsonquit (Ping timeout: 250 seconds)
22:55:16  * brsonjoined
23:16:11  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
23:40:14  * txjoined
23:40:25  * txpart ("undefined")
23:41:03  * laskar01joined
23:42:31  <laskar01>Hi, pardon a beginner, but is libuv the place to discuss maislot in Node?
23:46:08  * Fishrock|awaychanged nick to Fishrock123
23:47:23  <laskar01>mailslot as in Windows ? https://msdn.microsoft.com/en-us/library/windows/desktop/aa365130(v=vs.85).aspx
23:47:54  * zju3joined
23:49:42  * Fishrock123quit (Quit: Leaving...)