Chris G. Demetriou writes:
 > Frank van der Linden <frank@wins.uva.nl> writes:
 > > 	3) When called from the syncer itself, the softdep sync code may
 > > 	   may in fact allocate additional dependencies, albeit temporarily.
 > > 	   When its done, the total number of allocated dependencies will
 > > 	   have dropped, but in the meantime I may need to allocate
 > > 	   a few more elements, and can not fail on the hard limit.
 > > 	   It looks like I could use pool_prime to extend the pool when
 > > 	   the hard limit is reached. However, there seems to be no
 > > 	   call to shrink it again later.
 > 
 > sounds like you might want to have a "soft limit", which will cause it
 > to fail but which can be overridden with a special flag.

Is there a small upper bound on the number of these additional
transient elements?  Assuming the other restructuring discussed
elsewhere doesn't eliminate this issue, and that a nicer solution
isn't found or readily implemented, one could keep a small number of
reserved elements preallocated for this purpose if you can calculate
the number to reserve. At least as an interim measure.

--
Dan.