Please pardon my nose here, but if you can clarify some things I (and possibly many others) would be most grateful:

>>there is really only a single thread of execution, if you need to have several >identical instance of a method to execute simultaneously, ytou need to use MTS >to manage multiple instances of the object.
>
>Nope. Wrong answer <s>...
>
>Just because VFP is single threaded doesn't mean it can't run concurrent requests. Apartment Model Threading allows for this to work by loading
>in essence multiple copies of your server into memory and running them

How does the "in essence multiple copies of your server..." square with "they share a runtime,..." below? Here's how I interpret that: The server ('your server' in the statement) is actually reentrant, so the 'sharing' of the runtime (same thing as 'your server'???) means that even though multiples are processing, it is only the data (and GetMained) parts of the 'server' that take up *additional* resource.

>side by side. They share a runtime, and they run in a single process
>but all their data is separate - stored in Thread Local Storage (TLS).
>In essence your VFP component is in fact running on multiple threads
>simultaneously (as evidenced by my examples).

...So "they run in a single process" suggests to me that a single processing "slot" (my term) is used to dispatch these various "multiple copies", swapping the registers to match the applicable one to be dispatched now (and thus 'preserving' the locality of each 'servers' data.
>
>The tool must support this by providing true local data for all instances
>and VFP does this in the MTDLL implementation of VFP. It did not provide
>the data protection in 6.0 though, although it was Apartment Model Threaded.
>Since data was not local, the blocking was forced on the runtime. SP3's
>MTDLL localizes all data and the blocking disappears.
>
I have yet to get my hands on SP3, but reading a paper by Calvin H. on the topic suggests that there is specific coding required within the VFP application (server) to protect things in certain cases (SYS(2336,x), I believe). Is this function integral? Does this function get effectively NOOP'ed in a non-OLEPUBLIC implementation?


>MTS doesn't help or hinder this process in anyway. MTS is just another
>multi-threaded client for a VFP COM object, just as IIS/ASP can be.
>
>A *true* multi-threaded component can run in a process's MTA (multi-threaded
>apartment) which is more efficient. A single copy of this component

This statement leads me to believe that my prior scenario is out-of-whack. If my prior was correct then this method wouldn't be any more (or less) efficient, I should think.
Unless, of course, you mean that, while the prior method has the overhead of 'dispatching' within the same 'process', this method can initiate many simultaneous processes that essentially operate in a similar way. But in this case the "efficiency" hardly seems to be different. How is it more efficient?

>(data and code) can service all incoming requests because the component
>can run on any thread at any time. The component itself is responsible
>for being thread safe and isolating its data (typically via CriticalSections
>etc). COM doesn't need to fix up a special wrapper STA apartment for the
>object to run in first.
>
>MTA capable components can be very efficient, but IIS and MTS don't support
>them very well, so there's little benefit for them. MTA components make
>a lot of sense for ASP Application object components, but otherwise the
>benefits from standard MS apps is minimal.
>
I know that it is not your job to train me or anyone else on this stuff, but after reading things like "sink events' and 'save context' and all this stuff, confusion reigns, and if even Ed misstated things then possibly you could find some time to clarify some of this.

regards,

Jim N


>
>+++ Rick ---