Peter H.M. Brooks <pe...@new.co.za> wrote in message
news:aa630h$gh0$1@ctb-nnrp2.saix.net...
Quote
> "Smola" <supersmola...@VEinet.hr> wrote in message
> > "Peter H.M. Brooks" <pe...@new.co.za> wrote in message
> > news:aa1luj$a1a$1@ctb-nnrp2.saix.net...
> > > the only method that exists to share memory dynamically between
> > > processes is memory mapped files. At the bottom of this page it says
> 'A
> > > memory-mapped file can also be mapped by more than one application
> > > simultaneously. This represents the only mechanism for two or more
> > > processes to directly share data in Windows NT.'
> > > It may well be wrong, but it is pretty direct - and the page is
> > > copyright Microsoft 2002, so it is a fairly recent article.
> > This is correct and the examples are out there but you should search
> > Win32API groups since this is not exactly a Delphi issue and it all
> comees
> > to converting C API calls to Pascal. I can send you an example if you
> mail
> > me, but then again, Benjamin gave you a good answer.
> Yes, thank you for that. I agree that that is how it is at the moment.
> I wonder if it would be a useful extension to the language to be able to
> declare an export as 'shared' and have the compiler set up the mapping
> so that all processes using the same DLL would have access to the
> exported variables as shared global space. If it was an option I would
> imagine a lot more people would use it - this memory mapped file stuff
> does seem a long way round to do something quite simple!
I've been waiting for someone else to wade in here, but, I guess its only
myself that's intrigued by this one! ISTM that there are very good reasons
to deny the trivial mapping of one process's memory space into another. I
don't know the inner workings of the modern PC at all, but have designed
extensively with the 68K family in which, at the hardware level, process
memory spaces are rigorously mapped (if you choose to do it that way) and
there is no trivial way to get from one space to another. I have always
assumed that the use of file mapped memory in W32 is a kludge to get around
the problem, since IO memory is the only memory space separate processes can
hold in common. Perhaps you can tell me otherwise........ perhaps this is
off topic for this ng :-)
However, lets leave the nuts and bolts level. I have never found the need
for file mapped memory, and judging from the responses to this thread, it
can't be something people do very often. It's true I have considered it, but
there has always been a tidier solution. For example, I often need two
processes to communicate in control/dataflow situations that occur in
industrial instrument control. Here I've found COM to provide very simple
solutions from the point of view of my time and effort. This being
especially so when I have to provide a programming control interface for a
third party, as the interface publishes useful things like eneumerated
constants and data types.
You mention a possible scenaraio where you have a large number of processes
being generated in response to incoming data connection requests, and these
processes need to be able to share information. Isn't this why the OS allows
you to spawn child processes within your main process space? Certainly I
have found this a very useable approach. I won't say easy, as the
synchronisation issues demand careful thought.
My two centums .... no more!
Dave
