-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanups for MillBuildServer #2518
Conversation
For my understanding. How fast is the BSP server responding to the first BSP client initialize request? Does it answer the request in a timely manner, e.g. before a long-compiling |
It's the same on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Break
mill.bsp.worker.State
into a separate fileFold
targetTasks
intocompletableTasks
, and adjust all callsites to use thatMake
completableTasks
take atasks: BspModule => Task[W]
parameter, so we can perform all evaluation once up-front and then fall back to normal code after (rather than having it all execute in the context of the evaluator inside tasks, which obfuscates stack traces and evaluation order)Move
agg
param incompletableTasks
to a third parameter list, to allow type inference to work betterMake everything in
mill.bsp.worker
privateMove all the remaining BSP stuff from
main/
andrunner/
tobsp/
, remove weird reflection hacks to just use direct instantiation where possible since now they're in the same moduleremove the
BspServerStarter
/BspServerStarterImpl
layers of indirectionMove
BspConfigJson.scala
,bspConnectionJson
andcreateBspConnection
out ofbsp.worker
intobsp
since it doesn't depend on anything heavyweight that necessitates it being in the worker moduleMoved
def startBspServer
out ofmill.bsp.BSP
intomill.bsp.BspContext
, leavingmill.bsp.BSP
to just serve one purpose asmill.define.Module
rather than additionally being a grab-bag of helper logicSimplify the concurrency story around instantiating the
BspServerHandle
:startBspServer
was put in aFuture
, with the main result of theFuture
waiting on the server to terminate only to do some logging and discard the result, and the creation of theBspServerHandle
was propagated viaPromise
s and that the main thread wouldAwait
uponstartBspServer
, directly returning theBspServerHandle
when it completes (orLeft[String]
on error). Server termination is waited for in a side thread, that does nothing but calllistening.get()
and do logging when it terminates. We still need a global variable to pass it todef startSession
, but this can just be a@volatile var
rather than a globalPromise
Await
sOverall this PR tries to cut a lot of the unnecessary complexity and messiness around the BSP logic. This results in a substantial reduction in lines of code, while still keeping the core logic unchanged. Hopefully this will make things easier to maintain and debug going forward.
Tested manually using VSCode on
examples/misc/3-import-file-ivy