Improved File Block API Calls

A low-level ctFILBLK() call on an index file that contains more than one additional member may fail with an FUSE_ERR (46, file number already in use) error.

When establishing a low-level file block, the file block logic requires a user file number at the start of a consecutive range of two user file numbers that are not in use. However, an index having more than one additional member needs more than two consecutive user file numbers, and if the required number of user file numbers is not available, the attempt to open the index fails with FUSE_ERR. The file block logic now requests consecutive numbers up front to ensure an appropriate file number is obtained.

The ctFILBLK() could also hang in particular cases.The file block routine has a polling loop that attempts to clear threads out of the c-tree core. The logic first set a status byte on all threads that have the file(s) to be blocked open and are inside the core. Then it checks to see if any threads that don't respond to the status byte change are being blocked (for example., waiting for a lock to be released). If so, it attempts to "kill" the blocks. However, the logic did not account for an extreme timing issue that would permit the block to be acquired after the checks for blocks had been completed. The result was that the file block routine looped indefinitely without making progress on the object of clearing threads from the core.

Now the polling loop periodically rechecks the thread status, and it can clear blocks on subsequent passes around the loop. The thread that had its blocking lock request killed (the second application) returns from the lock request with an error FBLK_PND (801). This error signifies that a block attempt required the thread (application) to not complete its last request, and instead leave the core code.

In addition to fixing this specific looping problem, additional changes have been made to the logic:

1. An external request to kill the file block thread that occurs during the polling loop will now be detected, and the file block will be aborted and return a TUSR_ERR (7),
2. The polling is monitored such that in the event another unforeseen situation leads to the loop repeating without making any progress reducing the number of threads still in the core code, the file block routine will abort itself, returning an FBLK_ABT (842) error,
3. Messages are sent to CTSTATUS.FCS when it appears the polling loop is having difficulty clearing the threads,
4. Existing logic to recover from an error occurring after the polling loop has been corrected to ensure that the file block attempt is completely cleaned up, and this revised error recovery is also used in cases (1) and (2) above.

Note: The second thread in the above test will still receive an FBLK_PND (801) error when the file block routine is aborted in cases (1) and (2) above. Whenever a thread (application) receives an FBLK_PND (801) error it is free to retry the operation. If the block was successfully obtained, the retry will behave in accordance with the type of file block requested (the thread may be suspended or return an error). If the block was aborted (as in cases (1) and (2) above), then the retry should behave just as if no file block attempt had been made.