Обсуждение: Re: [PATCHES] fork/exec patch

[moved to hackers / win32]

Claudio Natoli wrote:

>Or do people have strong leanings towards "fix as you go along"? Just feels
>like that way could see us getting bogged down making things "perfect"
>instead of advancing the port...
>
>
>

w.r.t. Win32, I think the way to proceed is (in this order):
. make it work
. make it elegant
. make it fast

BTW, I agree with Bruce, you're doing excellent stuff. Now for the fun
part (signals).

cheers

andrew

Andrew Dunstan wrote:
>
> [moved to hackers / win32]
>
> Claudio Natoli wrote:
>
> >Or do people have strong leanings towards "fix as you go along"? Just feels
> >like that way could see us getting bogged down making things "perfect"
> >instead of advancing the port...
> >
> >
> >
>
> w.r.t. Win32, I think the way to proceed is (in this order):
> . make it work
> . make it elegant
> . make it fast
>
> BTW, I agree with Bruce, you're doing excellent stuff. Now for the fun
> part (signals).

Actually, no.  I thought fork/exec would be a real mess (as did Tom),
but Claudio has done an excellent job of producing a minimal patch.  The
work isn't done yet, but this small patch has taken us much closer, so I
assume signals will be even easier.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>
>
>> Now for the fun
>>part (signals).
>>
>>
>
>Actually, no.  I thought fork/exec would be a real mess (as did Tom),
>but Claudio has done an excellent job of producing a minimal patch.  The
>work isn't done yet, but this small patch has taken us much closer, so I
>assume signals will be even easier.
>



Well, it's speculation on both our parts :-). ISTM we'll need an
explicit event loop to check the shmem (or whatever we use to simulate
signals) every so often - maybe that will be easy, I don't know - I'm
interested to see what turns up. (Of course, if we were threaded we'd
just need a thread to watch for the event ...)

cheers

andrew

Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >
> >> Now for the fun
> >>part (signals).
> >>
> >>
> >
> >Actually, no.  I thought fork/exec would be a real mess (as did Tom),
> >but Claudio has done an excellent job of producing a minimal patch.  The
> >work isn't done yet, but this small patch has taken us much closer, so I
> >assume signals will be even easier.
> >
>
>
>
> Well, it's speculation on both our parts :-). ISTM we'll need an
> explicit event loop to check the shmem (or whatever we use to simulate
> signals) every so often - maybe that will be easy, I don't know - I'm
> interested to see what turns up. (Of course, if we were threaded we'd
> just need a thread to watch for the event ...)

Have you looked at the CONNX signal code on the Win32 page:

    http://momjian.postgresql.org/main/writings/pgsql/win32.html

It uses shared memory and events.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Have you looked at the CONNX signal code on the Win32 page:
>
>    http://momjian.postgresql.org/main/writings/pgsql/win32.html
>
>It uses shared memory and events.
>
>
>

Yes, and I just did again. I guess I must be missing something, though -
I don't see what in that code causes the signalled process to call the
handler corresponding to the signal. Maybe I'm just a little brain dead
today ...

andrew

Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Have you looked at the CONNX signal code on the Win32 page:
> >
> >    http://momjian.postgresql.org/main/writings/pgsql/win32.html
> >
> >It uses shared memory and events.
> >
> >
> >
>
> Yes, and I just did again. I guess I must be missing something, though -
> I don't see what in that code causes the signalled process to call the
> handler corresponding to the signal. Maybe I'm just a little brain dead
> today ...

In the CONNX code for kill() I see:

    sprintf(szEventName, "CONNX_SIGNAL_%x", (int) lPID);
    sprintf(szSharedMemoryName, "CONNX_SMEM_%x", (int) lPID);
    hSharedMemory = OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, szSharedMemoryName);
    if (hSharedMemory) {
        /* Call the signal handle for that process.. */
        void           *pData = MapViewOfFile(hSharedMemory, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(int));
        if (pData) {
            int             nReturn;
            HANDLE          hProcessHandle;
            DWORD           ExitCode;
            *(int *) pData = nSignal;
            UnmapViewOfFile(pData);
            /* Open the event handle of the other process */
            hEvent = OpenEvent(EVENT_MODIFY_STATE | SYNCHRONIZE, FALSE, szEventName);
            hProcessHandle = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, lPID);
            if (hEvent) {
                SetEvent(hEvent);
                /* Wait for Event to be processed. */
                do {
                    nReturn = WaitForSingleObject(hEvent, 0);

Now, I am no Win32 programmer, but the mixture of OpenFileMapping() and
OpenEvent() looked promising.  :-)


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073