
Hi all,

Dennis Bjorklund wrote:
> >  Also has to work on Unix too for testing.
> 
> Everything can not work in unix, CreateProcess() and fork() 
> are different.

True (but CreateProcess and "fork followed by exec" are pretty close). I
think what Bruce is implying is that, ideally, we'd like to keep things as
close as possible between Unix fork/exec and Windows code bases, so that:
	* it remains possible to advance the Windows port under a *nix dev
environment and
	* should (when!) issues arise in the Windows implementation, it will
be easier to identify and debug


Neil Conway wrote:
> For example, couldn't we write this data into a particular location in
> shared memory, and then pass that location to the child? That is still
> ugly, slow, and prone to failure (shmem being statically sized), but
> ISTM that the proposed implementation already possesses those
> attributes :-)

I agree that this is a better implementation.

Bruce, do we implement this now, or just hold it as something to revisit
down the track? I'm all for leaving it as is.

Moreover, in general, how do we handle things like this? IMHO, I'd rather
live with a few kludges (that don't impact the *nix code) until the Windows
port is actually a reality, and then reiterate (having the discussions as we
go along, however, is necessary). Perhaps adding a TO_REVISIT section to
your Win32 Status Report page?

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...

Comments?

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Mon, 15 Dec 2003 10:15:00 +1100
Claudio Natoli <claudio.natoli@memetrics.com>
Re: fork/exec patch
On Mon, 15 Dec 2003, Claudio Natoli wrote:

> Moreover, in general, how do we handle things like this? IMHO, I'd rather
> live with a few kludges (that don't impact the *nix code) until the Windows
> port is actually a reality

As long as it does not hurt the unix code it's not a big problem as I see
it. The usual open source solution is that since no one else writes the
code, you can do it the way you think works the best. To change this in
the future does not mean that everything else has to be rewritten which is 
good.

It does also not mean that one can not discuss the implementation. A fair 
amount of discussion is always good.

-- 
/Dennis


Mon, 15 Dec 2003 00:31:10 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: 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


Sun, 14 Dec 2003 18:43:54 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [PATCHES] fork/exec patch
Claudio Natoli wrote:
> > For example, couldn't we write this data into a particular location in
> > shared memory, and then pass that location to the child? That is still
> > ugly, slow, and prone to failure (shmem being statically sized), but
> > ISTM that the proposed implementation already possesses those
> > attributes :-)
> 
> I agree that this is a better implementation.
> 
> Bruce, do we implement this now, or just hold it as something to revisit
> down the track? I'm all for leaving it as is.
> 
> Moreover, in general, how do we handle things like this? IMHO, I'd rather
> live with a few kludges (that don't impact the *nix code) until the Windows
> port is actually a reality, and then reiterate (having the discussions as we
> go along, however, is necessary). Perhaps adding a TO_REVISIT section to
> your Win32 Status Report page?
> 
> 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...

Let's get it working first.  I have added an item to the Win32 status
page so we will not forget it.

-- 
  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

Sun, 14 Dec 2003 22:16:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] fork/exec patch
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

Sun, 14 Dec 2003 22:28:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] [PATCHES] fork/exec patch
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



Mon, 15 Dec 2003 13:23:14 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] [PATCHES] fork/exec patch
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

Mon, 15 Dec 2003 14:44:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] [PATCHES] fork/exec patch
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


Mon, 15 Dec 2003 16:12:13 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] [PATCHES] fork/exec patch
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

Mon, 15 Dec 2003 16:21:07 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] [PATCHES] fork/exec patch