Skip site navigation (1) Skip section navigation (2)

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-16 14:56:19
Message-ID: 3FDF1D13.9080404@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
Magnus Hagander 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 ...
> 
> 
> Can't find that part either, but a few questions for the implementation
> regardless of wether that code is around somewhere:
> 
> 
> At what times do signals actually *need* to be delivered? And at what
> points do the calling process need to be notified?
> 
> Actually interrupting a running process to execute a procedure in a
> thread can be pretty darn tricky - AFAIK you have to manually switch
> thread context and create an exception which you then catch, call
> handler, reset and continue.
> 
> However, if it's acceptable to have delivery only when the thread is in
> "alertable state" this should not be necessary. Then you can basically
> take two approaches depending on when you need the response:
> 
> If you just need a response that the receiving process has queued the
> thread handler, then create a separate thread that receives the signal
> and queues a user APC on the main thread. This will then execute when
> the thread enters alertable state.
> 

Actually, I see that in os-fix2.cpp there is code that sets up a thread 
that just polls for the event and then calls the corresponding handler.


> If you need a response once it has actually run, then the main thread
> needs to do signal polling now and then. This has the bad sideeffect
> that the main thread will block completely until the signal is
> delivered, which might be a while.
> 
> I don't know what the semantics are for kill() on unix there? And if it
> is sync, does postgresql actually need that property?
> 

kill() should return success upon the signal being queued, as I 
understand it - i.e. no sync.

All this kind of answers my original question, by pointing out the need 
to poll one way or another, which is why I suggested that signal 
emulation might be messy, and more complicated than the fork/exec case.

In effect, the runtime in Unix provides the signal polling for you for 
free, which is why this method of IPC is so commonly used.

cheers

andrew


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-12-16 15:25:05
Subject: Re: [HACKERS] 7.4.1 release notes
Previous:From: Peter EisentrautDate: 2003-12-16 14:47:45
Subject: Re: [HACKERS] 7.4.1 release notes

pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2003-12-16 15:21:52
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Tom LaneDate: 2003-12-16 14:23:33
Subject: Re: libpq.dll for win32 always using ssl

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group