request
Asks for a set of zones, which all close to new traffic at once and are held together.
All or nothing, and that is a rule rather than a convenience. Taking the zones one by one as they drain would let the holder hold part of a region while waiting for the rest, and a vehicle inside the region could then be waiting for a zone the holder holds while the holder waits for the zone the vehicle is standing in. That is a deadlock, and holding nothing until every zone has drained prevents it outright rather than leaving it to be diagnosed.
What it does not do is make a deadlock through a holder impossible. What a pending closure waits for is every vehicle occupying its reserved zones, and that wait runs through the reservation rather than through ZoneHolderIfc.awaitedZone, so two closures over abutting regions can still wait on each other. That case is prevented by the ordering rule on ZoneClosureIfc and reported by the detector when it survives.
Traffic already inside the region is let out rather than trapped -- see ZoneClosureIfc -- which is what makes the drain terminate however busy the region is. The cost is that a closure over busy space begins later, and that delay is measured rather than hidden.
The extent is chosen per occurrence, at run time, and the sources cost nothing: a link's zones by name, a junction's zone, a zone at a station, or a sample drawn from the network.
Return
the request, whose ZoneRequest.isGranted says whether the hold began at once
Parameters
who is taking the space
the zones to take, all on this guide path, distinct, at least one
told when the hold begins and when it ends