do you mean “Do not call C API functions (such as NSFItemScan) that require callback functions in your extensions manager” from capi user-guide?
what do you mean by “if I load my own dll library to Extension Manager”? you have an extmgr-dll and loading a second dll?
however this won’t make much difference at all.
if you’re inside one of the extmgrs you registered, e.g. NSFDbOpen, you should not use functions that have callbacks.
this might work, but for certain combinations / moments this could fail. so don’t expect if they work that you’re on the safe side. try to find a workaround…
there’s another warning about locked semaphores in user guide, i’ve ignored that one. run successfully for months on thousands of clients, but one day we had an issue with some clients (bad locations after 5->6.5 upgrade) - semaphore deadlock within extmgr. fortunately workaround was easy and costumer had tested upgrade before rollout.
this might have not neccessarely being caused only by an upgrade, but for whatever minor reason (maybe different policies?) - imagine what it would be like getting an early morning wake-up call telling you no ones being able to work in a big company.
if your application is just for a few people and used internally, or only on a test-server that you’re allowed to crash:) you could simply ignore that…
it would be nice to get some official statement, maybe this limitation was only valid for win16 calls? who knows?
i think it’s a warning about unwanted recursion, ie your emhandler gets called, your code then calls something that triggers your emhandler again for the same call. it has the possibility of recursing forever (been there, done that) until the server dies.
so long as the calls you make are not going to trigger the same call you’re already processing then you’re ok, if it can possibly trigger the same call then you’d better make sure that your code ignores the subsequent recursive calls