Re: [RFC] shutdown stages

 Okay we seem to agree on all the prerequisites and problems. Just the
 algorithm of choice differs.

 So separating the central issues into changes. Ordered by severity.

 1) pending async queue after the grace period is over / shutdown
 functions scheduling calls

 Insert a checking member to SignalEngine as an intermediary between
 other code and StopEventLoop().

 Problem: Can we get to Async queue size() from SignalEngine members?

 2) useless waiting / grace period

   How about a shutdown "ticker" style event?
   Rather than a blanket 30-second grace period jump. We schedule a
 shutdownTick() every second starting with shutdown signal arrival. The
 tick event checks to see if a) all transactions are over, or b) grace
 period has expired since its first call. Either way things can be kicked
 along, else it re-schedules itself in one more second.

 The alternative of scheduling it as a call could lead to very tight
 loops and CPU consumption. So I'm avoiding it for now despite
 potentially being a better solution in the long run. Events can be
 easily converted in a second round of optimization.

 Problem: How to best detect the number of active transactions?
   Do we have any global clients + internal transactions count already
 which I've been too thick to see?
   If not...every transaction manager object seems to have an
 AccessLogEntry in its members. (Recall that is why I suggested that
 object became Xaction master slab). A static counter of transactions in
 there could be used.

 Amos
Received on Tue Aug 09 2011 - 02:15:12 MDT