Hi, >> I have a question about hb_vmRequestReenter(). >> What is the rule to call it? > > It checks if HVM is active and ready to execute PRG code, > safe and restore RETURN value so it's not overwritten by > executed code and safe and restore HVM exception signals > so it's possible to execute PRG code even if QUIT or BREAK > exception is set. When it restores exceptions then if > necessary it merges saved exception and the exception set > by executed code. This are operations executed for current > HVM but it may change in the future. In general it tries > to adopt HVM for reentrant call.
I'll add it then to hbcurl and hbssl callbacks. >> If it must be called before hb_vmProc()/hb_vmSend()/hb_vmEval*()/?, > > It depends on context. If you want to respect above conditions > then yes. In most of cases the answer is yes. These calls are missing from hbbmcdx, xhb, rddsql and rddads, maybe it'd be worth to check if they need it or not. I'm still rather unsure when to use it in practice. >> shouldn't we add it to hb_evalLaunch() function to stay >> compatible with old code, where this requirement wasn't present yet? > > We do not use hb_evalLaunch() in core code so I cannot say how > it's used by 3-rd party code. It does not return pointer to > hb_stackReturnItem() so it's possible to encapsulate it and > probably it will not cause any problems for 3-rd party code. > It may interact only with code which expects that copy of > returned value is in hb_stackReturnItem(). It also effects > code which was interrupted by existing exceptions but in > Clipper the exception are check very unregulary so I do not > believe that anyone created code which strongly depends on > such behavior. In my opinion we can add it. I agree. If not defined by Clipper, we should go the safest way and do this for callers. hb_stack*() is not a primary API for users, ideally no 3rd party code should use it. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
