Of course, this is a shared library so you can't save stuff like this in local variables in the SLB. If Draconis does this then it's obviously buggy.Marathon calls appl_init as well as the slb (not executed by the caller but the slb-process), so it's quite obvious.
Yes, that's just wrong.
> That ist not done in draconis, else the slb would not call appl_init. I don't understand what you mean. Calling appl_init() in a SLB is not aproblem. But the apid must be saved in/by the calling application, not ina static variable in the SLB itself.I think the slb has its own apid, which differs from that of the caller.
If that's the case then there's a problem. Such a behaviour (SLB itself being an AES client) means that you can't use the AES cleanly from a SLB!
- appl_init() from the SLB will register the SLB as an AES client. But there can't be more than one AES client per process, so this SLB is no longer shared. - If a function in a SLB calls the AES and the AES sees this as a call from the SLB process, then the SLB must also call appl_init()...
So you're stuck ;)The AES must treat calls from a SLB function as if they're coming from the process that's calling this SLB function. If not, then SLB's can't work as intended.
Jo Even