On 22.03.2022 13:22, Rony G. Flatscher wrote: > The new native API "context->AddCommandEnvironment(name, handler, type);" > allows one to add a new > command environment in 5.0 at runtime according to rexxapi.pdf. > > Is it possible to do the opposite, i.e. remove such a command environment as > well?
So, no answer means "no"? Here is the background for this question: there may be use cases (in 7/24 scenarios) that benefit if rather than terminating Rexx interpreter instances (RII) one would become able to pool them (in situations where there is just a low number of RIIs in use in parallel, but many RIIs are needed during the uptime). For that to work it would be necessary to get a RII back to its pristine state in which nothing got configured for it, assuming that defined command environments are managed per RII. OTOH if command environments are global to all Rexx interpreter instances this would not apply and one would probably have to make sure that the default environment (assuming that is maintained per RII) is reset to "CMD" on Windows and "sh" on Unix (or would it be better to set to "SYSTEM" for all operating systems?). Also, only RIIs would get pooled that got created without any preconfigured handlers, i.e. RexxCreateInterpreter's third argument options is NULL. This also involves resetting .local, which would probably possible by creating a copy immediately after creation, and when trying to reset them to its pristine state set a copy of that copy (.local is relevant for .input/.stdin, .output/.stdout, .error/.stderr). If possible, it would be even better if a Reset() was available to the Instance context to allow context->Reset() such that ooRexx resets the RII. Any thoughts, comments? ---rony _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
