Prev: "Working set - Private" on XP
Next: CreateFileMapping fails on Vista but passes on XP
From: Andrew Falanga on 1 Feb 2008 15:27
Hi,

I've got something of a chicken and egg situation that I'm wondering
about. This has to do with the sharing of certain data between
separate processes (see some of my earlier postings). I'm trying to
duplicate a socket from one processes to another. The problem is, to
create the socket in the target process, one uses WSADuplicateSocket
in the source and WSASocket in the target.

In the target process, the WSASocket call requires a WSAPROTOCOL_INFO
struct which would be filled from the call to WSADuplicateSocket in
the source process. However, the WSADuplicateSocket call requires a
handle to the target process for the duplication of the socket. Thus,
the target process must be started and then the call to
WSADuplicateSocket.

The problem is, I'm concerned my target process will startup and
attempt to read from my shared memory area before I'm able to populate
it with the contents of the necessary WSAPROTOCOL_INFO structure
needed to create the duplicated socket. Basically, because the source
process must do; CreateProcess, WSADuplicateSocket, CopyMemory instead
of something like, WSADuplicateSocket, CopyMemory, CreateProcess.

Ok, that's the background, now the one question I have is, what
differences (from someone more familiar with winsock than I) are there
between a WSAPROTOCOL_INFO struct populated by WSADuplicateSocket and
a call to getsockopt to fill that structure? A cursory look at the
structure contents leads me to believe, not much, if any. The
structure doesn't seem to contain any process state information.
However, the MSDN documentation on WSADuplicateSocket says something
about getting a, "special WSAPROTOCOL_INFO" structure. This makes me
think there's something, well . . . special about the struct contents
when retrieved from WSADuplicateSocket versus getsockopt.

If there isn't any difference, great, I'll just get the struct from
getsockopt, copy it to the shared memory, then start my target process
and be done with it. However, I shouldn't rely on this (getsockopt
instead of WSADuplicateSocket), what mechanisms can I use to block the
target process until meaningful data is in the shared space? I've
looked at some (e.g. GetWriteWatch, but it's not applicable to 32 bit
platforms), but none seem to fit the bill, but I don't know all the
places to look.

Thanks,
Andy
From: Scott McPhillips [MVP] on 1 Feb 2008 23:40
"Andrew Falanga" <af300wsm(a)gmail.com> wrote in message
news:c5ba0518-d957-4ee5-8775-bd33ec53c4ff(a)j20g2000hsi.googlegroups.com...
> instead of WSADuplicateSocket), what mechanisms can I use to block the
> target process until meaningful data is in the shared space? I've
> looked at some (e.g. GetWriteWatch, but it's not applicable to 32 bit
> platforms), but none seem to fit the bill, but I don't know all the
> places to look.


You need some interprocess synchronization. Both processes would call
CreateEvent with the same unique event name. They both get a handle to the
same event object. Create the event non-signaled.

Target process calls WaitForSingleObject. This suspends the process until
the event is set.

Source process copies to the shared memory, then calls SetEvent. Target
process wakes up.

(CreateMutex could also be used, and is a better choice if you need two-way
synchronized access on shared memory data.)

--
Scott McPhillips [VC++ MVP]

From: Andrew Falanga on 1 Feb 2008 13:57
On Jan 31, 9:40 pm, "Scott McPhillips [MVP]" <org-dot-mvps-at-
scottmcp> wrote:
> "Andrew Falanga" <af300...(a)gmail.com> wrote in message
>
> news:c5ba0518-d957-4ee5-8775-bd33ec53c4ff(a)j20g2000hsi.googlegroups.com...
>
> > instead of WSADuplicateSocket), what mechanisms can I use to block the
> > target process until meaningful data is in the shared space? I've
> > looked at some (e.g. GetWriteWatch, but it's not applicable to 32 bit
> > platforms), but none seem to fit the bill, but I don't know all the
> > places to look.
>
> You need some interprocess synchronization. Both processes would call
> CreateEvent with the same unique event name. They both get a handle to the
> same event object. Create the event non-signaled.
>
> Target process calls WaitForSingleObject. This suspends the process until
> the event is set.
>
> Source process copies to the shared memory, then calls SetEvent. Target
> process wakes up.
>
> (CreateMutex could also be used, and is a better choice if you need two-way
> synchronized access on shared memory data.)
>
> --
> Scott McPhillips [VC++ MVP]

Thank you for this. This helped greatly.

Andy
 | 
Pages: 1
Prev: "Working set - Private" on XP
Next: CreateFileMapping fails on Vista but passes on XP