github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
japhb_ nwc10++ # Unrotting the bits 00:19
timotimo ohai japhb 01:10
how's things?
nwc10 good *, #moarvm 07:20
jnthn good * 10:16
nine good good! 11:01
nqp::exit really doesn't play well together with --full-cleanup. E.g. we may still have locked locks like quite ironically $the-end-locker. 11:02
Well our profiler is at least very consistent: it doesn't free any of its memory, ever. 11:11
jnthn Yup, another of those "we'll be exiting anyway, why do what the OS will do" :) 11:17
We might still have locked locks in a normal exit (e.g. all foreground threads finish) too 11:18
nine I worked around this by just unlocking all mutexes in gc_free if we're in global destruction already 11:24
jnthn Hm, can you just do that? I thought wrong thread unlocking a mutex was an abort also... 11:38
MasterDuke jnthn: extracting out the new MVMSpeshCandidatesAndArgGuards struct isn't going as easily as i'd hoped. maybe i should have started from a blank slate instead of adopting what i'd tried first. if you've a couple min to spare, does gist.github.com/MasterDuke17/fd236...07aad7722f look like it's on the right track? or am i 11:44
missing something blindingly obvious? i feel like i keep adding new conditionals that i wasn't expecting to need
nine jnthn: darn....you're right. Unlocking a foreign mutex results in either undefined behavior or an error returned 11:49
But, all hope may still not be lost. I can't do anything about someone manually locking a lock and allowing a thread to end with the lock in this state. But all well behaved code should be ok. After all full-cleanup does end all foreground and background threads gracefully 11:51
jnthn nine: I dunno, if I have a background worker that I don't care when gets pulled down, and it may acquire a mutex on occasion, then I don't think it's especially badly behaved 11:55
But it would be in trouble
(In the full-cleanup state) 11:56
nine So far to be OK with full-cleanp your background worker has to react to getting a vmnull from a queue by exiting and unlocking any mutex is holds. I guess that's reasonable to ask for? 11:57
jnthn Yes, though of course that means that --full-cleanup changes the semantics in that a task on the threadpool now can block shutdown 12:00
Given this mode is primarily for our own leak finding, though, I don't think that's a big deal 12:01
nine If your worker doesn't implement this, you may end up with a hang on exit or maybe an abort when run with full-cleanup. You'd get a panic now
The other use case is embedding. But there one can probably assume that either the code is more tightly controlled by the embedder anyway or additional rules can apply
timotimo could put in a timeout that panics the vm if a thread doesn't react to the shutdown request in time 13:07
also, we could inject exceptions into other threads as long as we can get them to wake up and run into a gc barrier 13:08
nwc10 this would be "wake up, time to die" ? 13:11
timotimo a good day to die in glorious combat!
[Coke] Qapla'! 13:14
brrt good * 16:01
nwc10 good *, brrt
Geth MoarVM/asan_fixes: 4 commits pushed by (Stefan Seifert)++ 16:50
ggoebel #raku 18:19
brrt ohai ggoebel 18:39
ggoebel o/ 18:40
brrt .tell nine it may be worth having a MVM_VECTOR_PARAM(x) macro that specifies the vector as a parameter, and maybe an equivalent MVM_VECTOR_ARG(x) that does the same for arguments
tellable6 brrt, I'll pass your message to nine
MasterDuke interesting. i now get a bit further in the nqp build, but get a segv in MVM_str_hash_key_is_valid, and the backtrace doesn't have any code i touched 21:52
timotimo: btw, i now get a bunch of new warnings in debugserver code 21:54
after i rebased my branch to master
timotimo i bet it's format strings again 22:01
MasterDuke nope 22:03
gist.github.com/MasterDuke17/68a01...182379a730
timotimo ah, those are harmless but can still be fixed easily 22:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!