Re: [HACKERS] [PATCHES] fork/exec patch

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>

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

[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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073