timotimo but still, starting, running and terminating the uv loop every time we want to read or write isn't terribly good 00:00
performance wise
leont It depends, really 00:02
timotimo in this case it's multiple short lines of text
and going via nativecall into puts gives much better performance than going through nqp::say
and there's quite some overhead to NativeCall. 00:03
leont But what if say would have blocked? (e.g. on a pipe or socket) 00:04
timotimo what about it?
we literally start the event loop, add a single thing to it - in this case stdout - and register a callback that immediately removes the thing from the event loop again, then we wait for the event loop to terminate 00:05
timotimo if it blocks, who cares, we block on the result anyway 00:05
[Coke] where is the mvm sub 'endprofile' implemented? 15:17
ah. it calls MVM_profile_end... 15:18
and the question should have been "mvm op", not "mvm sub". my bad. 15:20
Ven timotimo: %rip is the current instruction pointer, right? I don't understand why there's a word&long version of this register.. for historical purpose? 16:26
(asking timotimo++ because brrt++ isn't here :P)
(erm, *next* instruction pointer)
jnthn
.oO( It's called "rest in peace" 'cus that instruction will be retired soon... )
16:40
leont timotimo: hmm, that does sound suboptimal (re: say) 21:12
jnthn The big problem we have with sync I/O things at the moment is that handles end up having thread affinity in libuv 21:13
For async I/O it's all async, so nothing is blocking on it, so it's fine we throw all the work in a queue and a single thread is dedicated to running the event loop 21:14
But for sync I/O that model would create fairly intolerable overhead.
I mean, if what we have now ain't tolerable, that ain't gonna be :)
(The Moar async I/O event loop thread never actually runs any userland code at all, it just takes work from an input queue and shoves callbacks to run in the scheduler queue you give it with the task) 21:16
In hindsight, shoving all of our sync I/O stuff also through libuv was probably not so wise. 21:17
It seemed like a good idea to outsource handling platform specific things
But given you can count the platforms we care to support in the near future on the fingers of one hand, and even then it's basically POSIX and Windows, that probably wasn't so big a win either. 21:18
And the cost is that people pass sync handles around between threads and get really weird behavior.
leont I'm still observing async IO issues with Proc::Async :-/ 21:19
jnthn Such as?
leont It works fine as long as I have only one of them 21:20
If I have two, things blow up
jnthn :/
leont First is missing part of its data, second is hanging (and my signal handler isn't responding either)
(for sigint)
jnthn did have a Proc::Async thing running really nicely a month or two back 21:23
Wonder what happened
leont I've never seen it work nice
At least not with multiple processes
jnthn The thing I had ran a bunch of 'em.
Heck, I used it to manage a load of concurrent scp processes about a year ago after I first added it, and it was pretty stable. 21:24
jnthn should perhaps try things on more than one platform. :)
leont I don't know, maybe I'm doing something terribly wrong
jnthn Maybe, but it still sounds like something's wrong. 21:25
Is the thing you're trying to run anywhere I can try it out next week, once I'm back from teaching?
bah, was that sentence even English... :)
leont Just pushed a testing branch to tap-harness
jnthn OK 21:26
Found it
leont It's triggered by running bin/prove6 (against any p6.t)
jnthn OK, will give it a try next week (or maybe at weekend) and see what I can reproduce. 21:27
leont Thanks :-)
jnthn my $timer = $done.then({ now - $start-time }); 21:28
cute!
leont I'm planning to try to convert t/harness to it, and see what happens. Not having parallelization is suboptimal, but not a blocker at this stage I suppose. 21:29
jnthn ah, but
my $done = $process.start();
Are you using that promise to determine when the process ends? 21:30
leont Yes, the harness class is awaiting all those promises
jnthn OK 21:32
I'll have a look into it 21:33
But, teaching tomorrow, so I'd better rest now :)
'night
timotimo gnite jnthn!
leont Good night!