load-shared-library from non-main thread causes trace/BPT trap
calling (load-shared-object ...) from threads other than the main thread cause a trace/BPT trap. Apparently this used to be fine, but 10.6 supposedly changed the behavior here. Also, the root of the problem may be the CFInitialize might need to be called on the main thread and then things _might_ be ok.
Possible solutions include:
1. leaving this as is and making it the user's responsibility to make sure he or she is on the main thread when calling load-shared-
2. make (load-shared-object ...) interrupt the main thread and call dlopen from there
3. call CFInitialize from the main thread during the normal initialization sequence
Darwin Beaune.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-