class
CompilerJobQueue extends AnyRef
Instance Constructors
-
new
CompilerJobQueue(newExecutor: () ⇒ ThreadPoolExecutor)
Value Members
-
final
def
!=(arg0: Any): Boolean
-
final
def
##(): Int
-
final
def
==(arg0: Any): Boolean
-
final
def
asInstanceOf[T0]: T0
-
def
clone(): AnyRef
-
final
def
eq(arg0: AnyRef): Boolean
-
def
equals(arg0: Any): Boolean
-
def
executor(): ThreadPoolExecutor
-
def
finalize(): Unit
-
final
def
getClass(): Class[_]
-
def
hashCode(): Int
-
final
def
isInstanceOf[T0]: Boolean
-
final
def
ne(arg0: AnyRef): Boolean
-
final
def
notify(): Unit
-
final
def
notifyAll(): Unit
-
def
shutdown(): Unit
-
def
submit(result: CompletableFuture[_], fn: () ⇒ Unit): Unit
-
def
submit(fn: () ⇒ Unit): Unit
-
final
def
synchronized[T0](arg0: ⇒ T0): T0
-
def
toString(): String
-
final
def
wait(): Unit
-
final
def
wait(arg0: Long, arg1: Int): Unit
-
final
def
wait(arg0: Long): Unit
A thread pool executor to execute jobs on a single thread in a last-in-first-out order.
The last-in-first-out order is important because it's common for Metals users to send multiple completion/hover/signatureHelp requests in rapid succession. In these situations, we care most about responding to the latest request even if it comes at the expense of ignoring older requests.
To restrict unsafe multi-threaded access to the presentation compiler we schedule jobs to run on a single thread. We use this executor instead of the presentation compiler thread (see MetalsGlobalThread) for the following reasons: - we limit the usage of sleep/notify/wait/synchronized primitives. - some blocking compiler APIs like
ask[T](op: () => T)don't seem to work as advertised. - it's preferable to work on top of CompletableFuture[T] instead of the custom Response[T] from the compiler, which is required to execute tasks on the presentation compiler thread: