mutex is also apparently slower on OSX than Linux

also, thought a bit more about the strategy around engine work display/frontend stuff. I think because of the sheer number of executions in the engine, rather than displaying every single “workunit” we’d instead treat the display of work as a “sampling profiler” of sorts. basically, everytime a task kicks off we’ll register that with a new datastructure in the engine. then there’d be a frontend thread that samples that on an interval and update the curses swimlanes on the frontend (we’d port my hackweek display thing to rust). then the tasks that take the longest will be most visible there - and shorter lived tasks may never even surface in the UI. post run, we could spit out a more detailed report in chrome trace-viewer format which would help us actually profile where time is being spent in engine runs.

yea, makes sense.

configurable refresh rate.

yep

and maybe staggered across swimlanes so it looks more ‘active'

but yeah, may take a whack at that in an upcoming weekend

what was your hackweek display thing?

was basically an inline curses swimlane widget thing

but it was only ever using mock data

ah ok, uml type thing for activites?

no: a realtime display of what is running

was similar to the buck “power console”, except way cooler 😉

right, I am sure!

managed to rejigger the pantsd integration test sequence to repro the deadlock in CI. now let’s see if the lazy init fixes it up.

cool

(which CI? travis?)

yep

👍

👍

looks good on the roost as well, afaict

nice!

reviewable?

yep: https://github.com/pantsbuild/pants/pull/4412

@rough-minister-58256 : one comment. maybe not a blocker, but would be good to fix.

ah, k

thx

does https://github.com/pantsbuild/pants/pull/4412/commits/7f0471182542754348893ea632cc9f5dd6e0be02 look sufficient for that?

shipit