|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:06
nebuchadnezzar joined
00:07
p6bannerbot sets mode: +v nebuchadnezzar
00:09
ugexe joined,
p6bannerbot sets mode: +v ugexe
|
|||
| ugexe | I was investigating using uv_addrinfo to do async host name lookup, such as here: github.com/MoarVM/MoarVM/blob/d8e0...udp.c#L579 -- however the first parameter is a uv_loop_t, and the functions that do host name lookup do not get passed a uv_loop_t. A few functions inside asyncsocket.c do get passed uv_loop_t (void write_setup, void close_perform, | 00:10 | |
| void setup_setup, void read_setup) but it is never used for anything. Is the way forward to pass uv_loop_t to the functions that would call uv_addrinfo ( MVMAsyncTask * write_bytes_to and MVMObject * MVM_io_socket_udp_async )? Or should things be refactored such that the host name lookup takes place somewhere else? | |||
|
00:11
lizmat left
01:46
MasterDuke left
07:01
domidumont joined
07:02
p6bannerbot sets mode: +v domidumont
|
|||
| nine | Did you know? We compile 3093 frames (i.e. BEGIN blocks) during stage parse and another 425 during stage optimize. Compared to 15467 frames that are part of the normal compilation. | 08:47 | |
|
08:53
lizmat joined,
p6bannerbot sets mode: +v lizmat
|
|||
| nine | Median frame size is 236 bytes, so my guess to pre-size bytecode buffers to 256 bytes was surprisingly spot on :) | 08:53 | |
| This is arguably one of the most bizarre uses of a domain name: www.cdqe.de/ (make sure you have a look at the source code, too) | 14:15 | ||
|
14:35
domidumont left
14:40
domidumont joined
14:41
p6bannerbot sets mode: +v domidumont
14:47
domidumont left
15:02
fake_space_whale joined
15:03
p6bannerbot sets mode: +v fake_space_whale
15:23
zakharyas joined,
p6bannerbot sets mode: +v zakharyas
15:50
lizmat left
|
|||
| Geth | MoarVM/nqp-mbc: 13 commits pushed by (Stefan Seifert)++ review: github.com/MoarVM/MoarVM/compare/0...5885a7fd25 |
17:13 | |
|
17:23
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
18:10
domidumont joined
18:11
p6bannerbot sets mode: +v domidumont
19:04
zakharyas left,
zakharyas joined
19:05
brrt joined,
p6bannerbot sets mode: +v zakharyas
19:06
brrt left,
brrt joined
19:08
ChanServ sets mode: +v brrt
|
|||
| brrt | ohai | 19:10 | |
| .tell ugexe that an asynchronous function with a callback must run on the eventloop thread; them be the rules. You ought to be passed a uv_loop_t as a parameter | |||
| not sure if the bots are on this channel | |||
| yoleaux | brrt: I'll pass your message to ugexe. | ||
| ugexe | brrt: the two functions where uv_addrinfo would be swapped in do not receive a uv_loop_t parameter. are you suggesting i should add this new parameter? | 19:13 | |
| yoleaux | 19:10Z <brrt> ugexe: that an asynchronous function with a callback must run on the eventloop thread; them be the rules. You ought to be passed a uv_loop_t as a parameter | ||
| timotimo | ugexe: how does the code currently do things? does it use a blocking getaddrinfo? | 19:14 | |
| ugexe | timotimo: yes | 19:15 | |
| timotimo | OK, then we'll have to actually split the functions that used to call getaddrinfo in half | ||
| that's what's so fun about async coding in C | |||
| oh | |||
| but if you set the callback to NULL it will run synchronously instead | 19:16 | ||
| but your goal is to actually make it async? | |||
| ugexe | it still needs to be passed a uv_loop_t for the first parameter though | ||
| timotimo | or is there a different reason to replace getaddrinfo with uv_getaddrinfo? | ||
| ugexe | yes the goal is to make it async, and try to get the sync code to use it later ( for extra win32 stuffs ) | 19:17 | |
| timotimo | OK | ||
| do you need more assistance turning the functions that use the function that has getaddrinfo into async stuff properly? | 19:18 | ||
| brrt | ugexe: synchronous libuv functions actually can accept a NULL uv_loop_t, in general | 19:20 | |
| let me actually look at your patch for a second :-) | |||
| ugexe | possibly. there are a few functions that are passed uv_loop_t parameter, but it is never used -- so i question if adding the parameter to another function is the actually the right direction | 19:22 | |
| brrt | no, that would never work in this case | ||
| see | |||
| this function is enqueueing work for the event loop | |||
| And it is only on the event loop that there is a uv_loop_t structure | 19:23 | ||
| ugexe | github.com/libuv/libuv/blob/e4087d...nfo.c#L146 <- an example of using it sync, but it still passes a loop | ||
| timotimo | MAKE_VALGRIND_HAPPY(); | 19:24 | |
| <3 | |||
| brrt | so, I"m not sure if you can delay the bindaddr to setup_setup | ||
| but if you can, that's how you'd do it | |||
| ugexe | well there is also an instance of blocking getaddrinfo in write_bytes_to | 19:27 | |
| timotimo | that's udp? | ||
| brrt | you can totally call uv_getaddrinfo with a NULL loop | ||
| it'll work. at least on unix | |||
| and on windows as well | 19:28 | ||
| if you want it async, with a callback, then yes, you'll need a uv_loop_t | 19:29 | ||
| source: I just read both versions. Neither of them have a read on loop, if cb is NULL as well | |||
| ugexe | that'll make swapping out syncsocket.c MVM_io_resolve_host_name easy enough then | 19:30 | |
| swapping out getaddrinfo from MVM_io_resolve_host_name rather | 19:31 | ||
|
19:31
domidumont left
20:00
lizmat joined,
p6bannerbot sets mode: +v lizmat
20:02
brrt left
20:03
zakharyas left
20:04
zakharyas joined,
p6bannerbot sets mode: +v zakharyas
20:05
zakharyas left
20:06
zakharyas joined
20:07
p6bannerbot sets mode: +v zakharyas
20:33
robertle left
20:39
zakharyas left
23:57
AlexDaniel left
23:58
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
|
|||