🚀 go-pugleaf

Ok, this makes a bit more sense now - if the MMF already exists then calling 
CreateFileMapping() basically acts like OpenFileMapping.

Two things are still confussing me.

Firstly, in my application, my service writes events to an event log but at 
the same time, it also adds them to a stl vector.  My service will be the 
ONLY process that should be able to write to the MMF.  Is it still necessary 
to protect access with a mutex?  I'm not clear here how the mutex protects 
anything... I assum that the logic would go something like this:

// To write to the MMF
1) Try to open Mutex_1.
2) if Mutex_1 cannot be openned (i.e. nothing is using the MMF), create 
Mutex_1.
   3) Perform write operation on the MMF.
   4) Release Mutex_1
6) if Mutex_1 can be openned (i.e. something is using the MMF), - do what? 
Wait on it using WaitForSingleObject?

- would the same be try for reading.  This seems a bit bashful - surely 
there is some overhead in creating the mutex each time.  Also, in the case 
of (6) what action do you take if the mutex exists?  If you just wait on it 
with WaitForSingleObject, surely there is the potential to hang the service 
if another process creates the mutex and keeps it open?

Secondly, I can't get my head around the File Mapping Security and Access 
Rights.  I just need to know how to secure the services side of the MMF 
creating so that other processes can only read the contents.

Sorry if this seems a bit layman and many thanks for the previous posts.

Mike

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:48501f3a$1@newsgroups.borland.com...
>
> "Mike Collins" <its@TheBottomOfThePost> wrote in message 
> news:48500053@newsgroups.borland.com...
>
>> Currently I've been storing these in a STL vector but now I need
>> to provide access to this list, to another process.
>>
>> Having read a bit about this, it seems that a Memory Mapped
>> file would be the easiest option.
>
> Maybe, maybe not.  Since your service is doing live logging, you would 
> have to provide serialized access to the list so that other apps could not 
> query it at the same time it is being updated.
>
> It might be better to have the service expose a separate server 
> connection, whether that be a named pipe or TCP/IP socket or COM server or 
> other IPC mechanism, that other apps can connect to and query the data 
> using a structured protocol.  Then the service does not have to expose 
> direct access to its private memory.
>
>> I need my service to be able to read and write to the MMF
>> but I don't want any other process to be able to modify it...
>
> The service can create the MMF with read/write access, and each 
> application can open the MMF with read-only access.
>
>> Is CreateFileMapping() used to create a MMF
>
> Yes.
>
>> does my service create the initial MMF with CreateFileMapping(),
>
> Yes.
>
>> and does my secondary process get access to the created MMF
>> with the same API call, CreateFileMapping?
>
> It can, though in your situation it would be better to have the secondary 
> processes use OpenFileMapping() instead.
>
>> I'm assuming that using CreateFileMapping(INVALID_HANDLE_VALUE,...)
>> means that I don't actually have to physically create a file on disk 
>> initially?
>
> You don't create your own file at all, no.  The memory for such a MMF is 
> backed by the system paging file, though.
>
>> Can I increase or decrease the size of the MMF once I've called 
>> CreateFileMapping()
>
> No.  You would have to re-map it.
>
>> should I try and determine the maximum size that it will ever be, 
>> initially?
>
> Yes.
>
>> How to I secure the MMF so only my service can access it?
>
> If you do not provide a value in the lpName parameter of 
> CreateFileMapping(), then no other process will be able to find it to open 
> it.
>
> Alternatively, CreateFileMapping() has a lpFileMappingAttributes 
> parameter, so you can construct a SECURITY_ATTRIBUTES that grants access 
> to only your service process.
>
>> I'm looking at a code example in VC++ and the author seems to have
>> used a mutex to control access whilst reading or writing - is this 
>> necessary?
>
> Yes, if the contents of the MMF change dynamically.  You don't want a 
> secondary processes to read the data while the service is currently 
> writing it.  They could end up with incomplete/corrupted data.
>
>
> Gambit
>