RPC and signals - processing priority

They proposed that the program should check and process all user interrupts once per block while handling the chain in the background. However, another user named Wladimir provided a response clarifying that this issue is not related to priority or user interrupts, but rather to the locks on the wallet and client. According to Wladimir, each RPC command takes both locks and releases them only when finished. The shutting down process also requires both locks, resulting in serialized operations. This locking mechanism is implemented to protect the database and critical data structures. Although there may be scenarios where the locks are not necessary or read/write locks could be used for better concurrency, caution must be exercised in making such changes.The writer of this context is facing difficulties with the bitcoind software, which is not responding to various rpc queries and signals. They have noted that these actions are being recorded in the debug log, but they do not occur as expected. As a solution, the writer suggests that the software should incorporate a check and processing of all user interrupts once per block while simultaneously handling the chain in the background. Additionally, the writer expresses curiosity about how busy commerce servers handle this poor rpc handling and wonders if there is a way to increase the priority of user scheduled tasks. Overall, the writer seeks an explanation for the issues with the bitcoind software and possible solutions or workarounds.