github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: jstuder-gh++ created pull request #959:
More exprjit templates (09/05/18)		 03:02
brrt \o 07:56
brrt apparently, if you're waiting on a signal, libuv lets another thread take your locks... 08:59
Geth MoarVM: 722f093997 | (Bart Wiegmans)++ | src/jit/x64/tiles.dasc
[JIT] Add down-cast operations to cast_unsigned_load_addr

Had added them to cast_unsigned, but not in the loading version.		 09:13
Geth MoarVM/master: 9 commits pushed by (Jeremy Studer)++, (Bart Wiegmans)++ 10:21
brrt bumpmaster, bump maybe? 10:24
lizmat brrt: will do 10:28
brrt (passes spectest for me) 10:29
thankyou lizmat
lizmat looks like Zoffix beat me to it :-) 10:37
brrt :-)
timotimo since we already have the r script that can automate bumps for us, why don't we actually teach a bot to bump for us? maybe with a whitelist of users that are allowed to execute it.
the r script also runs test, as i understand it.
brrt that's actually a pretty good idea 10:38
I think I may be able to implement an unshift operation for ConcBlockingQueue
timotimo oh, putting elements at the front, eh?
brrt yes...
hmmm
timotimo sounds like a terrible footgun. would it be concurrency-safe, too? i'm not sure how CBQ internally implements locking or whatever 10:39
brrt yes, it would be concurrency safe, otherwise i wouldn't say it was possible :-)
timotimo right, of course
brrt it's really useful for head-of-line jumping?
in my case, I want to put the 'shutdown spesh thread' signal to move to the front of the queueu 10:40
timotimo right, though it's racy in the way that you won't be able to tell where in the queue you've landed
lizmat makes mental note to look into the "r" script
timotimo lizmat: that's zoffix' tool for internals development, it's neat.
brrt well, for any N threads that applied unshfit on queue Q, at least one of them would find its item at the front, and all of them would find them before any concurrent pushed item 10:41
the only trick that I think is a bit tricky, is updating the tail 10:42
there's two locks and a condition variable
a head lock and a tail lock
the shift/poll/peek operations all take a head lock 10:43
timotimo and resizing takes both, or something?
brrt the push operation takes a tail lock, and then optionally a head lock, when it finds the queue was empty
it's a linked list internally
single-linked
timotimo ah, OK
i could have known that just from the presence of a head and tail lock
hm. would you call a linked list with a head and tail pointer a degenerate case of a skip list? :) 10:44
brrt maybe, but it's not a good idea to assume that your conversation partners 'could have known' things :-)
I'm not sure, actually, because I'm not sure what is meant by a skip list
timotimo if i liked coffee, this wouldn't have been so hard :P
brrt anyway. I can implement unshift by taking the head lock first, and updating the head... but if I try to update the tail, I might find myself deadlocking if I lock the tail only then 10:46
timotimo right 10:47
brrt so. unshift needs to lock tail before locking head, just as push does
Zoffix lizmat: it's not "r" script; it's "z" script :) 11:12
huggable: zscript
huggable Zoffix, Helper script for Rakudo Perl 6 core development: github.com/zoffixznet/z
timotimo damn, sorry about that :|
Zoffix And to run bumps you just run `z bump` command. It pulls, makes commits, tests, and if tests are clean pushes, if not, asks you if you want to push
And it has a bunch of other commands, like for rebuilding nqp or moar or rakudo, etc 11:13
AlexDaniel well, heh, I've been doing `z f && z bump m && z bump n && z bump push` all that time :D 11:16
which was effectively `z bump` to type because Ctrl-r 11:17
but still :)
Geth MoarVM/fork-safety: 95d851ffc3 | (Bart Wiegmans)++ | 5 files
[Spesh] Tear down spesh worker in full_cleanup

If the spesh worker is still active the GC can try to free a lock that is being held, which leads to an abort in libuv. Stopping the thread makes full-cleanup work (although it still leaks).
Thread is stopped by signalling with VMNull. Ideally we'd unshift this to the front of the queue, but that is more complicated.		 11:38
MoarVM/fork-safety: 33c71bc3ef | (Bart Wiegmans)++ | 3 files
[ConcBlockingQueue] Unmoving body

The locks structure was already malloc'd, and I extended this to include the entire body. This prevents the GC from moving the body while we are blocked on acquiring a lock, simplifying the code, and has negligible cost.
MoarVM/fork-safety: 2dd82ec5c5 | (Bart Wiegmans)++ | 3 files
[IO] Stop event loop thread

Stop loop with uv_stop(uv_loop) and join the thread
brrt ^ rebase 11:47
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/09/11/...of-damian/ 12:19
brrt lizmat++ 13:02
Geth MoarVM/fork-safety: 6f804c0708 | (Bart Wiegmans)++ | 2 files
[ConcBlockingQueue] Implement unshift

Enable queue users to 'jump the line' and make sure that their item is delivered to the front of the queue. This has less concurrency than the push/shift pair, because it needs to lock both the head and tail locks. It should rarely be useful.
The motivating example in which it is, is shutting down the spesh worker thread, because it means we do not have to wait until the spesh thread has processed (now useless) work.		 16:05

Powered by Cro and the Raku® Programming Language.

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

Thank you!