Thread: Simplify Win32 Signaling code
This patch simplified Win32 signaling code per discussion in hackers. In this implementation, each process will have a named (by its pid) mutex, named shared memory area and named event in global namespace. The process is sending/receiving signals as the following: (*) the process who kill the signal: - Grab the named mutex, set signal bit in target process's shared memory area and SetEvent(), then it is done; (*) the process who should receive the signal: - the main thread of this process could be awakened by the event from waiting status(like semop()) or CHECK_FOR_INTERRUPTS() actively; -- there is no other threads of the process; Details could be found in this thread and follows: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01388.php Regards, Qingqing
Attachment
> This patch simplified Win32 signaling code per discussion in > hackers. In this implementation, each process will have a > named (by its pid) mutex, named shared memory area and named > event in global namespace. The process is sending/receiving > signals as the following: > > (*) the process who kill the signal: > - Grab the named mutex, set signal bit in target process's > shared memory area and SetEvent(), then it is done; > > (*) the process who should receive the signal: > - the main thread of this process could be awakened by the > event from waiting status(like semop()) or > CHECK_FOR_INTERRUPTS() actively; -- there is no other threads > of the process; > > Details could be found in this thread and follows: > http://archives.postgresql.org/pgsql-hackers/2005-05/msg01388.php Looking at this patch reminds me of another discussion we had: Signals sent by the postmaster *before the signaling code is running in the child* has to be handled. This is handled in the curernt code by creating the pipe in the postmaster and then inheriting it. You'll need something similar in this one - create the stuff in the postmaster and inherit it down. (this is the initial_signal_pipe and pgwin32_create_signal_listener(), which you removed) Sorry, forgot to bring this up earlier because I had completely forgot it. You'll find some details if you search the archives, I beleive. //Magnus
""Magnus Hagander"" <mha@sollentuna.net> writes > > Looking at this patch reminds me of another discussion we had: > > Signals sent by the postmaster *before the signaling code is running in > the child* has to be handled. > > This is handled in the curernt code by creating the pipe in the > postmaster and then inheriting it. You'll need something similar in this > one - create the stuff in the postmaster and inherit it down. (this is > the initial_signal_pipe and pgwin32_create_signal_listener(), which you > removed) > > Sorry, forgot to bring this up earlier because I had completely forgot > it. You'll find some details if you search the archives, I beleive. > Is this thread: http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00000.php It is my fault to ignore this - I just *simply* removed those lines ... I will look into the problem and come up with a patch. Regards, Qingqing
In thread: http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00010.php --- >Do we actually need to pass the handle, or could the subprocess reopen >the pipe for itself? Nope, we need to pass the handle. Only one process can be the server-side of the pipe, and once the postmaster has opened it, the child process can't do it - the only way to get it is through inheritance. --- In current implementation, we can reopen it, but the problem is that when postmaster should close those three (shmem, mutex, event) handles? So the best way is still "Postmaster create them, duplicate these handles in BackendParameters and the child inheritates them". Do I got your meaning? Regards, Qingqing
Hi! A quick-check (haven't checked any details) - your unconditional use of Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 with some limits (IIRC, tablespaces don't work, and the intaller definitly doesn't work). If we want to continue doing that (which I think we do), the global\ has to be conditional - used on 2000+, not used on <= NT4. //Magnus >-----Original Message----- >From: Qingqing Zhou [mailto:zhouqq@cs.toronto.edu] >Sent: den 4 juni 2005 15:26 >To: Magnus Hagander >Cc: pgsql-patches@postgresql.org >Subject: Re: Simplify Win32 Signaling code > > > >Revised patch to avoid "lost signals before signaling >mechanism is set up >in Win32". This was tested by plus a line: > > Sleep(10*1000); > >in the front of pgwin32_signal_initialize(). > > >Regards, >Qingqing >
Magnus Hagander wrote: > Hi! > > A quick-check (haven't checked any details) - your unconditional use of > Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 > with some limits (IIRC, tablespaces don't work, and the intaller > definitly doesn't work). If we want to continue doing that (which I > think we do), the global\ has to be conditional - used on 2000+, not > used on <= NT4. How should he make this change? Test OS version or use a different feature? -- 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
>> Hi! >> >> A quick-check (haven't checked any details) - your >unconditional use of >> Global\ will not work on NT4. With 8.0 we said we wanted to >support NT4 >> with some limits (IIRC, tablespaces don't work, and the intaller >> definitly doesn't work). If we want to continue doing that (which I >> think we do), the global\ has to be conditional - used on 2000+, not >> used on <= NT4. > >How should he make this change? Test OS version or use a different >feature? Test the OS version. The other feature that can be used is named pipes, and that's what we have today ;-) All other kernel objects that we could use all use the namespaces in the new format, but not back on NT4 //Magnus
Magnus Hagander wrote: > >> Hi! > >> > >> A quick-check (haven't checked any details) - your > >unconditional use of > >> Global\ will not work on NT4. With 8.0 we said we wanted to > >support NT4 > >> with some limits (IIRC, tablespaces don't work, and the intaller > >> definitly doesn't work). If we want to continue doing that (which I > >> think we do), the global\ has to be conditional - used on 2000+, not > >> used on <= NT4. > > > >How should he make this change? Test OS version or use a different > >feature? > > Test the OS version. The other feature that can be used is named pipes, > and that's what we have today ;-) All other kernel objects that we could > use all use the namespaces in the new format, but not back on NT4 Do we have any place now were we test the Win32 version, that he could use as an example, or is this configure.in stuff? -- 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
>> >> A quick-check (haven't checked any details) - your >> >unconditional use of >> >> Global\ will not work on NT4. With 8.0 we said we wanted to >> >support NT4 >> >> with some limits (IIRC, tablespaces don't work, and the intaller >> >> definitly doesn't work). If we want to continue doing >that (which I >> >> think we do), the global\ has to be conditional - used on >2000+, not >> >> used on <= NT4. >> > >> >How should he make this change? Test OS version or use a different >> >feature? >> >> Test the OS version. The other feature that can be used is >named pipes, >> and that's what we have today ;-) All other kernel objects >that we could >> use all use the namespaces in the new format, but not back on NT4 > >Do we have any place now were we test the Win32 version, that he could >use as an example, or is this configure.in stuff? It *must* be done at runtime. Because you use the same binary on NT4 and more recent versions! Nope, we don't have any checks like that today. It's fairly trivial, but if examples are needed, look at pginstca.c in the pginstaller project where we do this. //Magnus
""Magnus Hagander"" <mha@sollentuna.net> writes > > It *must* be done at runtime. Because you use the same binary on NT4 and > more recent versions! > > Nope, we don't have any checks like that today. It's fairly trivial, but > if examples are needed, look at pginstca.c in the pginstaller project > where we do this. > Ok, understood. Shall I patch it now or after you've seen the details the patch? And I don't have a NT on hand, so I hope I could do my best in imagination ;-) Regards, Qingqing