Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good 🦆, #moarvm 05:13
nine japhb: I don't see a good reason but we do take the mutex for all IO ops as a principle. There could still be a good reason for that. Apart from this, if MVM_io_read_bytes and MVM_io_is_tty are trying to lock the same mutex, one of them ought to win (and release the mutex once it's done). So I don't understand why it would deadlock? 07:27
lizmat www.theregister.com/2022/06/10/app...nt=article 11:13
meh
www.theregister.com/2022/06/10/app...cman_flaw/
nine So.... speculative execution is hard 11:23
timo as always ;( 11:34
just .. don't allow program code to get high resolution time values 11:35
sounds easy enough lol
japhb nine: It wasn't deadlocking just on the mutexes. It was other program logic. To whit, one thread was waiting in the read for the response to a terminal query string, which was never getting sent because I'd inserted the TTY check just before sending the terminal query string. And the query would never get sent because it was waiting on the mutex that the read already held. 12:02
timo the read stuff itself is async though, right? 12:11
japhb timo: Not on a syncfile. 12:44
timo ah 12:50
do we cache the result of .t btw? if so, then it'll be very fun to discover that it may lock if you have for some reason had something else call .t on it before and never realized until you, for example, tossed out some debug code 12:51
japhb timo: Nah, no caching that I'm aware of. I don't think isatty is an expensive operation (though it may be a syscall underneath, I suppose). 13:14