G
gus bjorklund
Guest
> On Apr 15, 2019, at 5:32 PM, dbeavon wrote: > > are you saying that multiple distinct _progres processes share a single AVM? sorry i was not clear. i will try again. without using the word "avm" (it has no actual definition). i mean that multiple _progres processes share the same memory-resident executable, hence they share the same /code/ (and static data (text strings, constants, etc.)). each process has its own process-private data and also shared data (like database shared memory, shared procedure libraries, etc.) inside the agent process, there are some number of threads that each have their own execution context. some of these threads are for running 4GL code and others are for other (internal) purposes. all of the threads in the process can see all of the data in the process but each has its own execution context. some of the process-private data in the agent process is the data associated with 4GL sessions (datbase connections, transactions, r-code, persistent procedures, 4GL call stack, 4GL created objects, 4GL variables, etc.). each 4GL session has a set of these things, all tied tegether. other process-private data is for the 4GL interpreter's use. each worker thread has an instance of the 4GL interpreter code and some related data. there is one copy of the 4GL interpreter code in the process (obtained from the executable, mapped to shared code segments by the operating system) and multiple copies of the (process-private) interpreter's data (one for each worker thread). when a worker thread gets a request, it finds the (process-private) session data associated with the target of the request and binds to it. it then collects the parameters that were sent and runs the 4GL r-code that was requested (i.e. called remotely by the client). when the request has been processed to completion, final results are sent back to the client and the worker thread unbinds from the session. it can then work on the next request which may be for the same or another session. one more point: code that is executed by the worker threads (or other threads) must be written specially so that it can work independently of all other threads. the 4GL interpreter has been extensively modified to be able to do this. to accomplish such a feat, one has to change many internal data structures and global variables so that there is a separate copy for each thread or arrange for a single copy to be used exclusively by one thread at a time (by locking and unlocking the data structure somehow). that is at the heart of the XML question that started this thread. the agent process apparently uses a single Xerces XML instance for all the XML work done on behalf of all the 4GL sessions. therefore when an XML operation is taking place, some internal lock prevents other threads from interfering with the handling of the in-process XML operation(s). this is not a Xerces bug. it is a 4GL agent limitation. it could be remedied without much effort, but that is easy for me to say because i dont have to do it. hope that is clearer.
Continue reading...
Continue reading...