Condividi tramite

VFP8R.DLL Run-Time Library

  • Articolo

Vfp8r.dll provides services for the following types of Visual FoxPro-generated applications:

  • Distributed applications (.exe files)
  • Out-of-process servers (.exe files)
  • In-process servers (.dll files)

This is the primary run time used by Visual FoxPro for most types of applications.

The Visual FoxPro run time, vfp8r.dll, does not service multiple in-process .dll Automation servers. Each in-process .dll now uses a separate instance of the vfp8r.dll run time. The following rules determine how in-process .dlls use the vfp8r.dll run time:

  • The in-process .dll first called has exclusive use of the vfp8r.dll run-time library (typically installed in the System folder or the System32 folder, depending on your operating system).

    If an in-process .dll already has exclusive use of the vfp8r.dll run time, a renamed copy of the vfp8r.dll run time is created on disk and loaded into memory for each in-process .dll called. The vfp8r.dll run time is assigned a name based on the name of the in-process .dll. For example, if an in-process .dll named Myserver.dll is called, a copy of the vfp8r.dll run time is renamed to myserverr.dll (note the "r" appended to the name) and is loaded into memory to service the in-process .dll. This can also occur with a Visual FoxPro .exe server creating an instance of a .dll server – a situation where both would be sharing the same run time from the same process.

  • Visual FoxPro run times are renamed only for in-process .dlls that run within the same process. This means that two separate clients, each running in their own process, can load two different Visual FoxPro in-process .dll files without the run time being renamed. In this case, both Visual FoxPro in-process .dll files use vfp8r.dll because the clients load in separate processes.

  • Multiple Automation servers, created with OLEPUBLIC clause in the DEFINE CLASS command, in a single in-process .dll share the same vfp8r.dll run time. In this case, it's possible that the Automation servers can affect each other by sharing PUBLIC memory variables, setting the same SET commands, and so on if they reside on a common thread. Be careful that multiple Automation servers in a single in-process .dll don't interfere with each other. The new Session class can help eliminate some of these conflicts. Using the multithreaded run time, vfp8t.dll, avoids these conflicts because objects created on separate threads will use their own separate memory space (thread-local storage).

You can use the vfp8r.dll library with in-process .dll servers. Because there are limitations in using vfp8r.dll, you should consider using the vfp8t.dll run time instead. The vfp8r.dll run time does not fully protect instance data and globals, therefore the library blocks multiple objects from executing code concurrently. If one of the objects is executing code, all other instances must queue up to execute code. As soon as the object executing code finishes, another object can enter the run time to begin its execution (whether it is a property assignment or method invocation). While this may not be ideal in many application scenarios, there are certain types of server applications where this may be the optimal approach.

If in-process (.dll) servers are deployed in a Component Services (or Microsoft Transaction Server) package, creating an instance of the server will load the .dll into the memory space of a Component Services process rather than the calling process. Moreover, multiple processes (.exe's) can instantiate Visual FoxPro .dll servers that will be loaded into a single Component Services process. Component Services generates (or reuses) a thread for each client requesting an instance (OLEPUBLIC) from a Visual FoxPro server. Since such applications often require enterprise scalability, there is the potential for many concurrent instances to access your Visual FoxPro server simultaneously. If only one client (instance) is allowed to execute code at a time, all others must wait. With a single processor machine, this may be fine, depending on the nature and execution times of methods in your server. Remember, a single processor can only run one line of code at a time.

You should always consider using the vfp8t.dll run time for multiple processor machines since each processor can simultaneously execute code for different objects. Since vfp8r.dll blocking behavior prevents simultaneous code execution, you should use vfp8t.dll for most situations.

See Also

Visual FoxPro Run-Time Libraries | VFP8T.DLL Run-Time Library | Interoperability and the Internet | Server Design Considerations and Limitations | Scalability and Multithreading