You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we spawn new nailgun servers, we currently do so under an (async) mutex on the entire pool. This means that while a server is spawning (which can take a few seconds: that's why we use nailgun in the first place), no other nailgun clients can get handles for servers.
To resolve this, the PoolEntry struct should likely begin to hold an async+fallible field, and the lock should be released as soon as it is inserted into the self.processes list, before knowing whether it has started successfully. If it fails, it can be cleaned up by the next consumer.
The text was updated successfully, but these errors were encountered:
As described in #13788, when we spawn nailgun processes, we currently do so inside the pool's lock. This blocks other processes from being acquired or started until the new server has started.
To resolve this, `PoolEntry`s now hold an `Option<NailgunProcess>` instead, which accounts for the fact that although they are eagerly started, the entry is potentially visible to other pool consumers before it has fully started.
Fixes#13788.
When we spawn new nailgun servers, we currently do so under an (async) mutex on the entire pool. This means that while a server is spawning (which can take a few seconds: that's why we use nailgun in the first place), no other nailgun clients can get handles for servers.
To resolve this, the
PoolEntry
struct should likely begin to hold an async+fallible field, and the lock should be released as soon as it is inserted into theself.processes
list, before knowing whether it has started successfully. If it fails, it can be cleaned up by the next consumer.The text was updated successfully, but these errors were encountered: