IREE项目中静态库加载器的多实例使用问题分析

问题背景

在IREE运行时环境中，开发者发现当尝试使用iree_hal_static_library_loader_create()函数创建多个静态库加载器实例时，系统无法正确识别已注册的库模块。具体表现为当开发者尝试注册引用其中一个库的模块时，系统会返回"NOT_FOUND"错误，提示没有找到名为'my_module_linked'的静态库。

技术细节分析

IREE的静态库加载器设计初衷是支持多个库的注册，这一点在iree_hal_static_library_loader_create()函数的注释中有明确说明。然而在实际实现中，当加载器尝试查找库时，如果未找到匹配项，会返回NOT_FOUND状态码，而调用链上游的代码却只检查CANCELLED状态码。

这种不一致导致了以下调用链中的问题：

1. 静态库加载器在查找失败时返回NOT_FOUND
2. 上层调用者(runtime/src/iree/modules/hal/loader/module.c和runtime/src/iree/hal/local/local_executable_cache.c)只处理CANCELLED状态
3. 导致有效的NOT_FOUND响应被错误地传播，而不是继续尝试其他加载器

解决方案

正确的实现应该是：

1. 静态库加载器保持返回NOT_FOUND状态码，因为这准确地反映了"未找到"的状态
2. 修改上层调用者的代码，使其同时检查NOT_FOUND和CANCELLED两种状态码
3. 当收到这两种状态码之一时，继续尝试其他可用的加载器

这种修改保持了语义的准确性(NOT_FOUND确实表示未找到)，同时修复了多加载器场景下的功能问题。

技术影响

这个修复对于IREE项目的以下方面有重要意义：

1. 模块化设计：确保多个静态库加载器可以协同工作
2. 错误处理：保持错误状态码的语义一致性
3. 扩展性：为未来可能添加的更多加载器类型奠定基础

最佳实践建议

对于使用IREE静态库加载器的开发者，建议：

1. 明确每个加载器实例的职责范围
2. 合理组织库的注册顺序，将最可能使用的库放在前面
3. 监控加载失败的情况，确保错误处理逻辑的健壮性

这个问题及其修复体现了IREE项目在模块化设计和错误处理机制上的不断完善，为开发者提供了更可靠的基础设施支持。