github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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?
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
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
Geth MoarVM/nqp-mbc: 13 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/0...5885a7fd25		 17:13
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!