|
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? | |||
|
06:20
frost-lab joined
|
|||
| nwc10 | good *, #moarvm | 07:20 | |
|
07:22
evalable6 joined
07:23
linkable6 joined
08:16
sena_kun joined
10:14
leont joined
|
|||
| 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 | ||
|
11:12
squashable6 joined
|
|||
| 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 | ||
|
11:57
Altai-man joined
|
|||
| 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 | |
|
12:00
sena_kun left
|
|||
| 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 | |||
|
12:38
frost-lab left
|
|||
| 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 | |
|
13:54
zakharyas joined
14:47
rypervenche joined
15:26
vrurg_ joined
15:29
vrurg left
15:59
sena_kun joined,
Altai-man left
16:00
brrt joined
|
|||
| brrt | good * | 16:01 | |
| nwc10 | good *, brrt | ||
|
16:40
patrickb joined
16:46
patrickb left
|
|||
| Geth | MoarVM/asan_fixes: 4 commits pushed by (Stefan Seifert)++ | 16:50 | |
|
17:07
leont left
17:17
Kaiepi left
17:43
domidumont joined
18:13
Kaiepi joined
18:16
domidumont left
18:19
ggoebel joined
|
|||
| 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 | ||
|
18:49
zakharyas left
19:13
leont joined
19:47
brrt left
19:57
zakharyas joined,
Altai-man joined
20:00
sena_kun left
20:06
tobs joined
20:11
tobs left
20:14
tobs joined
20:18
tobs left
20:21
tobs joined
21:00
tobs left
21:06
tobs joined
21:09
ggoebel left
21:11
tobs left
21:15
ggoebel joined
21:16
brrt joined
21:19
tobs joined
21:22
rypervenche left
21:25
rypervenche joined
21:35
zakharyas left
|
|||
| 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 | |
|
22:07
Altai-man left
22:30
brrt left
|
|||