I'll sum up this discussion in order to answer OP's questions:
athila13898684 wrote There is a delay of 211 milliseconds before and after calling the evalScript, being asynchronous isn't it supposed to give the control back immediately? |
CSInterface.evalScript is not, in fact, asynchronous. It is entirely synchronous and will block for the duration of the ExtendScript processing it triggers.
athila13898684 wrote My understanding of evalScript was that it should give the control back immediately and give the result whenever it is available but in this case it is happening the other way round, it is taking some time to give the control back along with the result(like a synchronous function). |
You are not alone in believing that this is how the function works. What is extra-confusing is that the function blocks but it does not immediately return the response. You still have to handle any returned values in a callback that you provide, which will be added to the normal event loop (message queue) and processed sometime later.
Yes, it is confusing.
athila13898684 wrote I'am calling csInterface.evalScript() which in turns calls a synchronous function inside a c++ library There is a delay of 211 milliseconds before and after calling the evalScript |
Both the CEP and the ExtendScript contexts process on the Main UI thread. Even if you were to delay the call into your C++ library, if it takes ~200ms to process something you would still cause a hitch in the UI - just later.
It may be possible, however, for you to make your C++ library perform its work asynchronously. There's a promising looking SoServerEval_f function defined in SoCClient.h (amongst others)... Once the work is done in your library (on a separate thread? time sliced somehow?) you might be able to trigger a callback into the ExtendScript context with some of the SoServer (?) APIs and then use the CSXS event system from there to dispatch an event back to CEP...?
AdChoices